Carebit MCP server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CAREBIT_SCOPE | No | Space-separated scopes to request on the token, e.g. `bookings.read clinicians.read`. When unset the token receives the project's full scope set, as the guide documents. Every scope named must be on the project or the token endpoint answers `400 invalid_scope`. | |
| CAREBIT_BASE_URL | No | Defaults to `https://api.carebit.co`. Used by the tests. | https://api.carebit.co |
| CAREBIT_CLIENT_ID | Yes | The API credential's client ID, sent in the token request body. | |
| CAREBIT_ALLOW_WRITES | No | `true` to register `create_human_task`, `create_booking` and `cancel_booking`. Off by default. | |
| CAREBIT_CLIENT_SECRET | Yes | The API credential's client secret, sent in the token request body. Never logged or included in an error message. |
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 |
|---|---|
| get_organizationA | The Organization this credential belongs to (name, type, contact details, address, currency, time zone) and, by default, the access token's granted scopes and developer project, so you know which other tools will work. |
| list_cliniciansA | The Organization's clinicians with display name, title, specialty and id (the id other tools take). Practice email addresses only with include_contact_details. |
| get_clinicianC | One clinician by id. |
| get_clinician_agendaA | A clinician's diary for a date range (at most 45 days inclusive, as the API documents): bookings, availability intervals and unavailability intervals in time order, each with start and end time, location and services. Bookings carry the patient's name; the patient's contact details, date of birth, NHS number and address, and the booking's free-text information, only with include_contact_details. Availability shows the schedule, not bookable times: use find_availability for those. |
| find_availabilityA | Times a clinician can be booked for a service variant (list_services gives service_variant_id). With start_date and end_date (at most 45 days inclusive) it lists every slot in the range (GET /v1/availability_slots); without end_date it returns the next slot on or after start_date (today when omitted), searching up to 8 months ahead (GET /v1/next_availability_slot). Results account for existing bookings, unavailability, service duration, buffers and rooms, include services patients cannot book online, and ignore the Patient Portal's minimum notice. |
| list_bookingsA | Bookings in the Organization. Diary queries need start_time_from and start_time_to (UTC; a bare date is taken as the whole day), a range of at most 30 days, or 90 days with patient_id, ordered by start_time. For the recall statuses awaiting_recall, overdue_for_recall, recall_expired and recall_canceled omit the time window (those bookings have no start_time; results are ordered by recall_due_date); did_not_attend still needs it. Filters are ANDed and sent as documented: clinician_id, patient_id, status, updated_since. Patient names are returned; their contact details and the booking's free-text information only with include_contact_details. |
| get_bookingA | One booking: status, times, clinician, patient (name by default), service and variants, location, payor, recall and cancellation details. Contact details and the free-text information fields only with include_contact_details. |
| search_patientsA | Patients with an active connection to the Organization, filtered with the exact-match filters the API documents (all case-insensitive; ANDed): first_name, last_name, date_of_birth, email, phone_number, or up to 25 ids. There is no partial-name search. Without filters the whole connected list is paged. Names, sex and patient number are returned; contact details, date of birth, NHS number and address only with include_contact_details (a search by email or phone still confirms that such a record exists). |
| get_patientA | One patient by id. Name, sex and patient number by default; contact details, date of birth, NHS number, address, third-party identifier and payment-method link only with include_contact_details. |
| list_invoicesA | Invoices in the Organization with status, totals, outstanding and paid amounts (minor currency units), supply date, payor type, patient and booking ids and line items. Filters sent as documented: booking_id, patient_id (ANDed). The Patient Portal payment link only with include_contact_details. |
| get_invoiceA | One invoice by id with its line items. Line-item titles and invoice notes are the practice's own text and go through the redaction unless include_contact_details is set. |
| list_paymentsA | Payments in the Organization with status, amount (minor currency units), method type, payor type, invoice and patient ids and any refunds. Filters sent as documented: patient_id, paid_at_from, paid_at_to (UTC; payments with no paid_at are omitted when a bound is set). Stored card details are never returned. |
| list_human_tasksA | The Organization's staff task queue (HumanTasks), newest first: content, due date, urgency, completion, assignees, patient and document ids. Filters sent as documented: patient_id, staff_member_id, document_id, is_completed (false for open tasks only). |
| list_servicesA | The Organization's services with duration, online-bookable flag, tax rate and their variants (id, price in minor units, clinician and location it is specific to). Variant ids are what find_availability and create_booking take. Filter sent as documented: is_bookable_online. Names and descriptions are the practice's own text and go through the redaction unless include_contact_details is set. |
| list_locationsB | The Organization's locations (clinics) with their addresses. |
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 15 tools
Most tools target distinct resources or actions, but the scheduling-related tools (get_clinician_agenda, find_availability, list_bookings) all return diary, availability, or booking data, creating some risk of misselection. The descriptions help clarify boundaries, but the overlap is not fully eliminated.
All tool names use snake_case with a consistent verb_noun pattern (get_, list_, search_, find_). The verbs are semantically appropriate and predictable, with no mixing of conventions.
15 tools is at the upper end of the typical 3-15 range and covers most entities in the clinic domain. Each tool earns its place, though some list/get pairs could potentially be consolidated without losing functionality.
The surface is almost entirely read-only and misses key lifecycle operations: no create_booking despite being referenced by find_availability and list_services, no update or cancel booking, no patient creation, and no invoice or payment write actions. These gaps would block common clinic workflows and cause agent failures.