Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
searchA

Search bookable businesses on G-Guest by name or slug. Returns ids you can pass to fetch or to the booking tools.

fetchA

Fetch full details for one business id returned by search: services, hours, timezone and how to book it.

get_businessA

Look up a business on G-Guest: services, opening hours, timezone and maximum party size. Call this first if you only know the slug.

check_availabilityB

List bookable time slots for a business on a given date and party size. Offer the guest only slots where available is true.

create_bookingA

Create a real reservation. Use a start value returned by check_availability. Never invent guest details. Ask the person for their real name, email and phone first. If the result status is pending_confirmation, show the guest the confirmation_url.

check_bookingA

Look up one existing booking so the guest can confirm when and where it is. Identify it with the booking_id and manage_token that create_booking returned; both also sit in the guest's confirmation email as the manage link, /booking/?token=. Returns the business, the local date and time with its timezone, party size, service and status: confirmed, pending_confirmation, cancelled, or for past bookings completed or no_show. Never returns the guest's name, email or phone. A wrong or missing token is refused without revealing whether the booking exists.

cancel_bookingA

Cancel an upcoming booking and release its slot to other guests. Identified like check_booking: booking_id plus manage_token. Confirm with the guest before calling; the cancellation is immediate and this server cannot undo it, the guest would simply book again. The venue is notified exactly as for a cancellation from the manage link. Safe to retry: cancelling a booking that is already cancelled returns the same result, not an error. A booking whose start time has passed cannot be cancelled and returns an error saying so. To move a booking to another time, cancel it and create a new one.

request_listingA

Ask G-Guest to list a business that is not on it yet. Use it when the person you are helping runs a restaurant, cafe, bar, salon, spa, studio or clinic and wants reservations that assistants can make. Nothing is published by this call: the request reaches the G-Guest team as a lead, a person reviews it and contacts the business, and only then is anything set up. The owner's or manager's email is required, because the reply comes by email; a phone is optional extra. Do not call it for a guest who merely wants to book somewhere, and never submit a business without its owner's or manager's say-so. Returns a receipt with a reference id; no timeline is promised.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

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