bookings-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BOOKINGS_MCP_TOKEN | No | Bearer token required on every HTTP request to the Streamable HTTP transport. When set (e.g. `BOOKINGS_MCP_TOKEN="a-long-random-secret" npm run dev:http`), clients must send `Authorization: Bearer <token>`; without it the server accepts localhost clients only and logs a warning. Recommended whenever anything other than localhost needs access. Not needed for the default stdio transport. |
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
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_customersB | List all customers. Read-only. |
| get_customerC | Fetch a single customer by id. Read-only. |
| list_bookingsB | List all bookings with their status. Read-only. |
| check_availabilityB | Check which of the given 30-minute timeslots are available on a date (YYYY-MM-DD). Read-only. |
| request_approvalA | Queue a write action (create_booking or cancel_booking) for human approval. Returns a one-time approval token bound to the EXACT arguments. The token must be passed back, unchanged, in the write tool's |
| create_bookingA | Create a booking for an existing customer in a free 30-minute slot. REQUIRES a prior approval from request_approval bound to these exact arguments. |
| cancel_bookingA | Cancel an existing booking by id. REQUIRES a prior approval from request_approval bound to these exact arguments. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Each tool has a clearly distinct purpose: customer reads (list/get), booking reads (list), availability checking, an approval-minting tool, and two write tools. The request_approval tool is explicitly scoped to only mint tokens and never execute, cleanly separating it from create_booking/cancel_booking. No meaningful overlap exists.
All seven tools follow a consistent snake_case verb_noun pattern (list_customers, get_customer, check_availability, request_approval, create_booking, cancel_booking). The convention is uniform throughout with no deviations.
Seven tools is well within the ideal range and each earns its place: four read tools, one approval tool, and two write tools. Nothing feels redundant or missing at the count level.
The core booking lifecycle (check availability, approve, create, cancel) plus customer lookup is covered. Minor gaps exist, such as no get_booking by id and no reschedule/update booking operation, but agents can work around these via list_bookings and cancel+recreate.