Skip to main content
Glama
README.md
# G-Guest MCP server

Book a table, an appointment or a place in a class at a real local business,
from an AI assistant, with no API key and no account.

G-Guest is the booking system those businesses run on. This server exposes it to
assistants over MCP: find a venue, read its real availability, and create a
booking that is confirmed instantly and appears in the venue's own panel.

**Endpoint** · `https://g-guest.app/api/mcp`
**Transport** · streamable HTTP (JSON-RPC 2.0 over POST)
**Auth** · none. Reading and booking are open; a booking must carry the guest's
name, phone and email.

## Tools

| Tool | What it does |
|---|---|
| `search` | Find bookable businesses by name or slug |
| `fetch` | Full details for one business: services, hours, how to book |
| `get_business` | The same card, by slug |
| `check_availability` | Real bookable slots for a date and party size |
| `create_booking` | A real, confirmed reservation |

Exact schemas: [`tools.json`](./tools.json), generated from the live endpoint,
not written by hand.

## Guest languages

The booking page, the confirmation, the reminders and the manage page speak the guest's language. Pass it on `create_booking` as `language` (ISO 639-1): `en`, `nl`, `de`, `fr`, `es`, `it`, `id` or `bg`. Defaults to English. The venue's own words (its name, dishes, class names) are never translated.

## Two ways to connect

**By URL**, if your client speaks streamable HTTP. Point it at
`https://g-guest.app/api/mcp`. Nothing to install.

**By command**, if your client expects a local stdio server, which is what
Claude Desktop and Cursor configs usually want:

```json
{
  "mcpServers": {
    "g-guest": {
      "command": "npx",
      "args": ["-y", "g-guest-mcp"]
    }
  }
}
```

That command runs the small proxy in this repository. It forwards every call to
the hosted endpoint and hands the answer back unchanged: no booking logic runs
on your machine, and no key is needed. `GGUEST_MCP_URL` overrides the endpoint
if you are pointing at something else.

The tool list is not written into the proxy. It asks the live server for it at
start-up, so the wrapper cannot fall behind the service; with no network it
falls back to the `tools.json` in this repository, which is generated from that
same endpoint.

## Try it without installing anything

```bash
curl -s -X POST https://g-guest.app/api/mcp \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
```

A live demo venue is `demo-studio` (a pilates studio) and `demo` (a restaurant).
Booking against those is real but harmless: they are ours.

## Adding it to an assistant

- **Claude, Codex, and custom agents**: point them at the endpoint. Nothing to
  install.
- **ChatGPT**: add it as a connector (developer mode). Step-by-step, with what
  we have actually tested and what we have not:
  https://g-guest.app/ai

## Honesty about what this is

Every venue reachable here is a paying or trialling customer of G-Guest, and a
booking made through this server is a real reservation that a real business will
honour. There is no marketplace in the middle and no commission on the booking.

We list only what we have tested ourselves. `https://g-guest.app/ai` says which
assistants have actually created a confirmed booking here, and on what date.

## Where the code lives

**The booking engine is not here and never will be.** Availability, slot
arithmetic, the guest list, everything that decides whether a table can be sold:
that lives inside the G-Guest application and stays there.

What this repository does hold is the stdio proxy in `src/`, about a hundred
lines whose entire job is to pass JSON-RPC through and return the reply as it
came. It exists because a good half of the clients and directories expect a
command to run rather than a URL to call, and because a sandbox has to be able
to build and introspect the server without reaching our infrastructure.

`tools.json` is regenerated from the live endpoint. If the two ever disagree,
the live endpoint is right.

## Links

- Service manifest · https://g-guest.app/.well-known/g-guest.json
- OpenAPI (plain HTTP, for agents without MCP) · https://g-guest.app/openapi.json
- What works today, per assistant · https://g-guest.app/ai
- G-Guest · https://g-guest.app

Made by [G-Lab Studio](https://g-lab.studio).

TDQS

A3.9/5.0

Scored across 8 tools

Disambiguation4/5

Most tools map cleanly to distinct operations—availability, existing booking lookup, cancellation, business discovery, and onboarding. The only real ambiguity is between fetch and get_business, which both return business details and are differentiated mainly by id versus slug.

Naming Consistency4/5

create_booking, cancel_booking, check_availability, check_booking, get_business, and request_listing follow a clear verb_noun pattern. fetch and search are bare verbs, so two tools break the pattern, but overall the naming is still readable and predictable.

Tool Count5/5

8 tools is well-scoped for a booking assistant: discovery, availability, booking lifecycle, and onboarding each have coverage. No tool feels redundant or superfluous.

Completeness4/5

The booking lifecycle is covered end-to-end via availability, create, check, and cancel, with moving a booking explicitly handled by cancel-and-recreate. Business discovery and listing-request flows are present, though there is no in-server update or confirmation action; the confirmation_url is delegated to the guest, so minor gaps remain.

Maintenance

ActivityMaintained
ResponsivenessNo issues