Appointedd MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| APPOINTEDD_API_KEY | Yes | Your organisation's API key from Appointedd (Settings > API), sent as the X-API-KEY header. | |
| APPOINTEDD_BASE_URL | No | Base URL for the Appointedd API. Defaults to https://api.appointedd.com/v1. | https://api.appointedd.com/v1 |
| APPOINTEDD_ALLOW_WRITES | No | `true` to register the write tools (create_reservation, create_booking, cancel_booking, create_customer and update_customer). Off by default. |
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 |
|---|---|
| find_available_intervalsA | Available start times (intervals) for a service between two dates/times, with the resources free at each and any group bookings with space. This is a query sent as POST /availability/intervals/search; it changes nothing. Use one of the returned start times with create_reservation. |
| find_available_datesA | Dates on which a service has availability between two dates/times, with the resources free on each. This is a query sent as POST /availability/days/search; it changes nothing. Use find_available_intervals for the start times within a date. |
| list_servicesA | Services offered by this organisation: name, category, booking type, occupancy, durations with prices, buffers, and the booking questions asked. Emails and phone numbers in names, descriptions and question text are redacted unless include_contact_details is set. |
| get_serviceA | One service by ID, with its booking settings (type, occupancy, durations and prices, buffers, group bookings) and booking questions. |
| list_service_categoriesC | Service categories (id and name) used to group services. |
| list_resourcesA | Resources in the organisation (staff members, rooms, equipment) with the services each is assigned to and its resource groups. Filter by service to see who can deliver it. A resource's email, phone and address are only returned with include_contact_details. |
| list_resource_groupsA | Resource groups (id and name), e.g. teams or locations that resources belong to. Useful as resource_group_id in the availability searches. |
| list_bookingsA | Bookings with status, service, resource, times, price, spaces and participants (customer IDs, spaces, arrival status, source). Filter by a date range (after/before compare with the booking's start/end including buffers), creation or update time, status, service, category, resource, customer or booking IDs. Participants carry customer_id only; use get_customer for names. Customers' free-text answers and single-use reschedule links are withheld unless include_contact_details is set. |
| get_customerA | One customer by ID: name, tags, marketing opt-in, custom fields and, unless max_bookings is 0, their bookings with the latest start first. Email, mobile, phone and address are only returned with include_contact_details. |
| find_customersA | Search customers by part of their name, email, mobile or phone (UK numbers match with 0 or +44). The API has no search parameter, so this pages through the customer list (100 per call) up to max_pages. Names only by default; contact details with include_contact_details. Note that a match on an email or phone fragment still confirms that such a detail exists on the account. |
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 10 tools
Most tools have clearly distinct purposes: get_customer (single by ID) vs find_customers (search), and list_services vs get_service are well separated. The one near-pair, find_available_dates vs find_available_intervals, is explicitly distinguished in the descriptions (dates vs start times), so confusion risk is low.
All ten tools follow a consistent snake_case verb_noun pattern (find_*, get_*, list_*), and the verbs match the semantics (find for search, get for single fetch, list for collections). No style mixing.
Ten tools is well-scoped for a booking/availability API, with each tool covering a distinct resource or query (availability, customers, services, categories, resources, groups, bookings). Nothing feels redundant or bolted on.
The surface is essentially read-only: availability search plus listing/getting customers, services, resources, groups and bookings. No mutation operations exist even though find_available_intervals explicitly points users to create_reservation, implying booking creation (and cancel/reschedule/update) is a notable missing part of the lifecycle.