Hosted MCP server for Cliniko — patients, appointments, availability, and invoices for AI agents.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4/5 across 17 of 17 tools scored.
Each tool targets a distinct resource-action pair such as patients, appointments, invoices, treatment notes, or availability. Even the two availability tools are clearly separated by description: list_available_times returns multiple slots while next_available_time returns one.
Tools consistently use the cliniko_ prefix with get_, list_, or create_ verbs before a resource name. The only notable deviation is cliniko_next_available_time, which lacks an explicit verb, but the overall pattern remains predictable and easy to navigate.
At 17 tools, the server is on the higher end but still reasonable for a practice-management API covering account info, businesses, practitioners, patients, appointments, invoices, treatment notes, products, and availability. Each tool maps to a meaningful endpoint, though next_available_time could be seen as partially redundant with list_available_times.
The core booking workflow is covered well: clients can look up availability and create appointments, and patient lookup is supported. However, there are no update, delete, or cancel operations for appointments or patients, and invoices and treatment notes are read-only, leaving notable lifecycle gaps.
cliniko_create_appointmentCreate an appointmentAWRITE — books a REAL new individual appointment in the live Cliniko practice. Requires patient_id, practitioner_id, business_id, appointment_type_id, and starts_at (ISO 8601). ends_at defaults from the appointment type if omitted. POST /individual_appointments.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | Appointment notes. | |
| ends_at | No | End time, ISO 8601. Defaults from the appointment type if omitted. | |
| starts_at | Yes | Start time, ISO 8601 e.g. 2026-07-20T09:00:00Z (required). | |
| patient_id | Yes | Patient id (required). | |
| business_id | Yes | Business id (required). | |
| practitioner_id | Yes | Practitioner id (required). | |
| appointment_type_id | Yes | Appointment type id (required). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reinforces the destructiveHint annotation with 'WRITE' and goes further by emphasizing this creates a 'REAL' appointment in the 'live' practice, highlighting real-world side effects. It also discloses the defaulting behavior for ends_at, which annotations do not cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences plus the endpoint identifier carry all essential information. The WRITE stance, required parameter list, default behavior, and endpoint are each presented once with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with complete schema coverage and a destructiveHint annotation, the description provides everything needed to invoke it correctly: required IDs, ISO 8601 timing, the ends_at default, and the live-practice consequence. No output schema exists, but the absence of return-value detail does not impede correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents every parameter including ISO 8601 format and the ends_at default. The description mainly restates the required parameter set and the default, adding no new semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'WRITE — books a REAL new individual appointment', naming a specific action and resource, and distinguishes it from the sibling create_patient. It also specifies the endpoint POST /individual_appointments, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this when actually booking a live appointment, as opposed to fetching or listing appointments or checking availability. It does not explicitly name alternatives or say when not to use it, but the create/list distinction in the sibling set makes the intended use obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cliniko_create_patientCreate a patientAWRITE — creates a REAL new patient record in the live Cliniko practice. Requires first_name + last_name. POST /patients.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City. | |
| No | Email address. | ||
| notes | No | Free-text notes. | |
| state | No | State / region. | |
| address_1 | No | Street address line 1. | |
| last_name | Yes | Patient last name (required). | |
| post_code | No | Post / ZIP code. | |
| first_name | Yes | Patient first name (required). | |
| country_code | No | ISO country code, e.g. AU. | |
| phone_number | No | A phone number (stored as a Mobile phone number). | |
| date_of_birth | No | Date of birth yyyy-mm-dd. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by explicitly marking the operation as 'WRITE', emphasizing that it creates a 'REAL' record in the 'live Cliniko practice', and providing the HTTP endpoint. This informs the agent that the call has real side effects. It does not discuss irreversibility or duplicate handling, but the destructiveHint annotation already signals side-effect risk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the critical write/side-effect information, states requirements, and includes the endpoint. Every word earns its place, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the flat schema and complete parameter documentation, the description is adequate for invoking the tool. However, there is no output schema and the description does not mention what the API returns (e.g., the created patient's ID), which an agent would likely need for subsequent steps such as creating an appointment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 11 parameters. The description only restates that first_name and last_name are required, which is already encoded in the schema's required array. It adds no extra semantic detail about formats, defaults, or relationships between fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'creates a REAL new patient record in the live Cliniko practice.' It identifies the verb, the resource (patient), and the fact that this is a write operation. The POST /patients detail further disambiguates it from the many read/list siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the mandatory prerequisites ('Requires first_name + last_name'), which helps the agent know when it can be called. However, it does not explicitly discuss when to use this tool versus alternatives or mention scenarios where it should not be used. Usage is implied by the operation name rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cliniko_get_accountGet account detailsAGet the Cliniko account and subscription details for the authenticated API key. A good first call to sanity-check auth, shard, and User-Agent. GET /account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include readOnlyHint=true, and the description is consistent with it, adding the diagnostic purpose of validating auth, shard, and User-Agent. It also reveals the endpoint and that the scope is tied to the authenticated API key, which is useful behavioral context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each with a distinct job: state the operation, state its recommended use, and state the HTTP endpoint. No filler or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool, the description covers what it does, who it acts for, and when to call it, which is enough for selection and invocation. It does not enumerate response fields, but the absence of an output schema and the generic 'account and subscription details' phrasing keep this a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, so there is no parameter information for the description to supplement; per the rubric this is a baseline 4. The description still clarifies that the call uses the authenticated API key implicitly, which is the only meaningful semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), object ('Cliniko account and subscription details'), and scope ('for the authenticated API key'), making it clearly distinct from sibling per-resource get/list tools. The addition of 'GET /account' reinforces the exact operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly flags itself as 'A good first call to sanity-check auth, shard, and User-Agent,' giving an agent a concrete trigger condition for choosing it. It does not contrast siblings, but no other sibling targets account-level auth/subscription info, so the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cliniko_get_appointmentGet an appointmentAFetch a single individual appointment by id. GET /individual_appointments/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Individual appointment id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description is consistent with that ('Fetch', 'GET'). It adds the endpoint and singular-appointment behavior, but does not mention error cases, response contents, or other edge behavior; adequate for a simple read-only fetch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The first sentence front-loads the essential operation and the second provides the precise endpoint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only get-by-id tool, the description, schema, and annotations together cover everything needed to invoke it correctly. Nothing important is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the only parameter, id, with its own description. The description adds that the id identifies the appointment and appears in the URL path, but this is marginal beyond the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Fetch') and resource ('a single individual appointment by id'), and the HTTP path reinforces the targeted resource. It is clearly distinguishable from the list and create siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this when you need exactly one appointment and have its id. It does not explicitly name alternatives such as cliniko_list_appointments for multiple results, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cliniko_get_invoiceGet an invoiceAFetch a single invoice by id. GET /invoices/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Invoice id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the GET method and id-based lookup, but does not disclose behavior such as error handling, response format, or authentication requirements. It adds modest context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short clauses with no filler. It is front-loaded with the action and resource, then gives the endpoint. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with one parameter and a read-only annotation, the description is mostly complete. The only minor gap is that without an output schema, it does not explicitly state what the returned invoice data will look like, but this is reasonably inferable from the resource name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description's '{id}' reference directly mirrors the documented 'id' parameter. The description adds no additional meaning beyond the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Fetch') and resource ('a single invoice by id'), and includes the exact HTTP endpoint. This clearly differentiates it from sibling list tools like cliniko_list_invoices and other get_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving one invoice by ID, but it does not explicitly state when to use this tool versus cliniko_list_invoices or other get_* tools. No exclusions or alternative routing are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cliniko_get_patientGet a patientAFetch a single patient by id. GET /patients/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Patient id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description aligns by saying 'Fetch' and 'GET /patients/{id}'. It does not add deeper behavioral context such as 404 handling or return format, but given the simplicity of the operation and the annotation coverage, a neutral score is appropriate. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence plus the endpoint, with no filler or redundancy. The key scoping information ('single patient by id') is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only lookup with one required parameter, no output schema, and no nested objects, the description and annotations are sufficient for an agent to invoke it correctly and understand what it returns. The return value is adequately implied by 'Fetch a single patient'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage with 'Patient id.' for the single parameter. The description adds that the id is the path segment in 'GET /patients/{id}', which is mildly useful, but the schema already carries the parameter semantics, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Fetch') and resource ('a single patient by id'), which clearly distinguishes it from list_patients and other get_* sibling tools targeting different resources. Including the exact endpoint 'GET /patients/{id}' further reinforces its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for retrieving one existing patient by its id, and the sibling names help differentiate it from listing/search tools. However, it does not explicitly state when not to use it or name an alternative, so it stops short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cliniko_get_treatment_noteGet a treatment noteAFetch a single treatment note by id. NOTE: treatment notes are protected health information (PHI). Read-only. GET /treatment_notes/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Treatment note id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's 'Read-only' is expected but redundant. It adds meaningful context by flagging treatment notes as protected health information (PHI), which is a useful behavioral and compliance cue. The HTTP endpoint also provides a concrete implementation detail beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no wasted words. The core action is front-loaded, followed by the PHI warning and endpoint, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read tool, the description is complete. It states what is fetched, by what identifier, that it is read-only, and that PHI sensitivity applies. No output schema exists, but the description sufficiently implies the return payload without needing to explain it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'id' parameter already has a clear description ('Treatment note id.'). The tool description adds no additional parameter meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('a single treatment note by id'), making the action and scope clear. It also includes the HTTP endpoint, which reinforces the resource and distinguishes this tool from list-type siblings like cliniko_list_treatment_notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates this tool is for fetching one treatment note by its id. It does not explicitly name alternatives or state when not to use it, but the 'by id' scoping is enough to guide an agent away from list operations for most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cliniko_list_appointmentsList appointmentsAList individual appointments, optionally filtered by patient/practitioner/business/type and a starts_at date-time window (starts_from / starts_to, ISO 8601). GET /individual_appointments.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (1-based). Default 1. | |
| sort | No | Field to sort by, e.g. created_at. | |
| order | No | Sort direction. asc | desc. | |
| per_page | No | Results per page (max 100). Default 50. | |
| starts_to | No | Only appointments starting before this ISO 8601 time (q[]=starts_at:<). | |
| patient_id | No | Filter by patient id (q[]=patient_id:=). | |
| business_id | No | Filter by business id. | |
| starts_from | No | Only appointments starting at/after this ISO 8601 time (q[]=starts_at:>). | |
| practitioner_id | No | Filter by practitioner id. | |
| appointment_type_id | No | Filter by appointment type id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates that this is a safe read operation. The description adds the endpoint and date/time filter window, but does not mention pagination behavior, response shape, or sort/order defaults. With annotations covering the safety profile, this is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The core action and resource are front-loaded, followed by the optional filter summary and endpoint. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with 10 optional parameters and no output schema, the description captures the main behavior and filter families, and the schema covers the remaining detail. It does not describe the response shape or pagination explicitly, but given the readOnly annotation and the richness of the input schema, the definition is complete enough for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents each parameter. The description groups the filters into patient/practitioner/business/type and specifies ISO 8601 date-time format, which adds modest interpretive value, but it largely summarizes what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('List individual appointments') and adds the endpoint 'GET /individual_appointments,' making the operation unambiguous. It also enumerates the filter dimensions, which distinguishes it from single-resource tools like cliniko_get_appointment and from list_available_times.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states clearly what the tool does and what optional filters exist, so an agent can infer when to call it. However, it does not explicitly name alternatives or state when not to use it (e.g., for a single appointment use cliniko_get_appointment). Usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cliniko_list_appointment_typesList appointment typesAList appointment types (service definitions). GET /appointment_types.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (1-based). Default 1. | |
| per_page | No | Results per page (max 100). Default 50. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description need not restate safety; the 'GET /appointment_types' line is consistent but adds little beyond the annotation. No additional behavior such as pagination, rate limits, or response shape is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action and resource, and every phrase earns its place. The endpoint string is a useful concrete addition rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only list operation with two optional pagination parameters fully described in the schema, the description is nearly complete. A note on the returned structure would be helpful, but nothing critical is missing for selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both page and per_page have explicit descriptions and defaults in the schema. The description adds no parameter information, but the schema already carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the exact action ('List') and resource ('appointment types') and clarifies that these are service definitions, which distinguishes it from sibling tools that list appointments or other resources. The endpoint string further disambiguates the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical 'service definitions' provides useful context, but the description never explicitly states when to prefer this tool over siblings like cliniko_list_appointments or when not to use it. Usage must be inferred from the name and resource type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cliniko_list_available_timesList available timesAList bookable appointment slots for a business + practitioner + appointment type within a date range (from/to, yyyy-mm-dd, span <= 7 days). High-value booking-slot lookup. GET /businesses/{business_id}/practitioners/{practitioner_id}/appointment_types/{appointment_type_id}/available_times.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Range end yyyy-mm-dd (cannot be more than 7 days after `from`). | |
| from | Yes | Range start yyyy-mm-dd (cannot be more than 7 days before `to`). | |
| business_id | Yes | Business id (path). | |
| practitioner_id | Yes | Practitioner id (path). | |
| appointment_type_id | Yes | Appointment type id (path). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds the GET endpoint and the 7-day range constraint. There is no contradiction, but the description does not disclose behavior like response shape, pagination, or timezone handling beyond what annotations and schema already imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core action and resource. The phrase 'High-value booking-slot lookup' is vague filler that does not add meaningful guidance, which keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential invocation context: resource identity, date range, and the 7-day span limit. With a complete input schema and readOnly annotation, this is mostly sufficient, though a note on the response contents or differentiation from next_available_time would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds little beyond restating the ids and the date range, which are already present in the schema property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('bookable appointment slots') scoped to business, practitioner, appointment type, and date range. It clearly distinguishes itself from siblings like cliniko_list_appointments by focusing on 'bookable' slots rather than booked appointments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for range-based availability lookup through the date range and 7-day span constraint. However, it does not explicitly mention when to choose this over cliniko_next_available_time or other alternatives, leaving the comparison to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cliniko_list_businessesList businessesAList businesses (practice locations) in the account. GET /businesses.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (1-based). Default 1. | |
| per_page | No | Results per page (max 100). Default 50. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds account-level scoping ('in the account') and the HTTP GET endpoint, which clarifies the operation's scope and method, but it does not disclose response format or pagination behavior beyond what the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence, front-loaded with the action and resource, followed by a clarifying parenthetical and the endpoint. Every element earns its place; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation with only two optional parameters, the description plus schema and annotations provide sufficient context. The readOnlyHint covers safety, the schema documents pagination, and the description clarifies the resource scope. No critical gap prevents an agent from invoking it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'page' and 'per_page' fully documented in the schema. The description adds no parameter-specific information beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('List'), a concrete resource ('businesses'), and clarifies that these are practice locations within the account. The inclusion of the endpoint 'GET /businesses' removes ambiguity, and since no sibling tool targets businesses, it is clearly distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternatives, nor are alternatives mentioned. The usage is only implied by the name and description (e.g., when a list of businesses is needed). There are no exclusions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cliniko_list_invoicesList invoicesAList invoices, optionally filtered by patient. GET /invoices.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (1-based). Default 1. | |
| sort | No | Field to sort by, e.g. created_at. | |
| order | No | Sort direction. asc | desc. | |
| per_page | No | Results per page (max 100). Default 50. | |
| patient_id | No | Filter by patient id (q[]=patient_id:=). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes that this is a safe read operation, lowering the bar for the description. The description adds the endpoint 'GET /invoices' and the patient filter, but does not disclose response format or pagination behavior. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence plus the endpoint, with no wasted words. The core action and optional filter are front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a low-complexity list tool with all parameters documented in the schema and a readOnlyHint annotation. The description covers the core behavior; the main omission is the return shape, but that is not critical for a straightforward list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's mention of optional patient filtering aligns with patient_id but does not add meaning beyond what the schema already provides for any parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List invoices,' which clearly distinguishes this from the single-resource sibling cliniko_get_invoice. The optional patient filter adds useful scoping. This is a clear, unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: to list invoices, optionally filtered by patient. It does not explicitly name alternatives or exclusions, but the intended use is readily inferable from the list-versus-get distinction among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cliniko_list_patientsList patientsASearch/list patients. Name/email filters use Cliniko 'contains' matching (q[]=field:~value). GET /patients.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (1-based). Default 1. | |
| sort | No | Field to sort by, e.g. created_at. | |
| No | Filter by email (contains match). | ||
| order | No | Sort direction. asc | desc. | |
| per_page | No | Results per page (max 100). Default 50. | |
| last_name | No | Filter by last name (contains match). | |
| first_name | No | Filter by first name (contains match). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the read-only behavior is covered. The description adds the Cliniko 'contains' matching rule and q[] parameter syntax, which are useful behavioral details not present in annotations. It does not disclose return format or pagination behavior beyond what the schema already documents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single well-structured sentence with the primary purpose front-loaded and the filter behavior appended. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter read-only list endpoint with rich schema descriptions and no output schema, the description is adequate but thin. It does not state what a response contains or pagination defaults, though those are inferable from the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented, including 'contains match' on filter fields. The description's mention of 'contains' matching is redundant with the schema, though the q[]=field:~value syntax adds a small implementation detail. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Search/list patients,' a specific verb and resource, and references the endpoint 'GET /patients.' This clearly distinguishes a list operation from sibling tools like cliniko_get_patient.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose this tool versus siblings such as cliniko_get_patient or cliniko_list_appointments. The description explains filtering mechanics but provides no use-case context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cliniko_list_practitionersList practitionersAList practitioners in the account. GET /practitioners.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (1-based). Default 1. | |
| per_page | No | Results per page (max 100). Default 50. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already covers the read-only nature. The description adds the GET method and account scope, but discloses no further behavioral traits such as pagination or response format beyond what the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the purpose ('List practitioners in the account') and followed by the endpoint reference. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with two optional, well-documented pagination parameters and no output schema, the description is sufficient. The account scope is stated, and the endpoint reinforces the behavior, though response details are left unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both page and per_page already described. The description adds no additional meaning about either parameter, so it meets the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States the verb 'List' with the resource 'practitioners' and scope 'in the account', backed by the HTTP endpoint GET /practitioners. This unambiguously distinguishes it from sibling list tools for appointments, patients, invoices, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. The description only states what the tool does, so usage context is implicit from the name and sibling set rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cliniko_list_productsList productsAList billable products/items. GET /products.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (1-based). Default 1. | |
| per_page | No | Results per page (max 100). Default 50. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the safety profile, and the description reinforces it with 'List' and 'GET.' No additional behavioral details are provided, such as pagination behavior, ordering, rate limits, or what exactly 'billable' excludes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one clear purpose statement followed by the endpoint. Every word earns its place, and the endpooint detail is genuinely useful without adding noise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with two optional pagination parameters and no output schema, this description plus the input schema is nearly sufficient. A minor gap is that it does not explicitly state that the response is a paginated list of product objects, though the pagination parameters imply it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameters with clear descriptions of page and per_page, including defaults and limits. The description adds no parameter-level meaning, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('billable products/items'), and confirms the specific endpoint with 'GET /products.' This distinguishes it from sibling tools, none of which target products.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the resource name 'products,' and the read-only nature is clear. However, the description does not explicitly state when to use this tool instead of alternatives or mention any exclusions or adjacency to related list/get tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cliniko_list_treatment_notesList treatment notesAList treatment notes, optionally filtered by patient. NOTE: treatment notes are protected health information (PHI) — handle with care. Read-only. GET /treatment_notes.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (1-based). Default 1. | |
| per_page | No | Results per page (max 100). Default 50. | |
| patient_id | No | Filter by patient id (q[]=patient_id:=). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description reinforces this with 'Read-only' and the HTTP method. More importantly, it adds a crucial behavioral warning that treatment notes are PHI and should be handled with care—valuable context beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences with no wasted words. The core action and optional filter are front-loaded, followed by a meaningful PHI warning and endpoint confirmation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The definition is complete for a simple read-only list operation: what it lists, optional filtering, safety profile, and PHI sensitivity are all covered. Pagination parameters are fully described in the schema, though the absence of an output schema means a brief note on the return shape would have been slightly more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description only restates the patient filter concept without adding format or syntax details beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('treatment notes'), and immediately notes the optional patient filter. This clearly distinguishes it from single-resource siblings like get_treatment_note and from other list tools by resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this is for listing treatment notes with an optional patient filter. It does not explicitly name alternatives or state when not to use it, but the list-vs-get distinction is strongly implied by the wording and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cliniko_next_available_timeNext available timeAGet the single next bookable slot for a business + practitioner + appointment type (optionally from a date). GET /businesses/{business_id}/practitioners/{practitioner_id}/appointment_types/{appointment_type_id}/next_available_time.
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Optional earliest date yyyy-mm-dd to search from. | |
| business_id | Yes | Business id (path). | |
| practitioner_id | Yes | Practitioner id (path). | |
| appointment_type_id | Yes | Appointment type id (path). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates that this is a safe read operation, and the description reinforces this with 'Get' and the GET endpoint. The description adds the 'optionally from a date' condition but does not disclose extra behavioral details like error handling, timezone behavior, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core behavior. The second sentence restates the endpoint path, which is somewhat redundant with the schema but still useful for clarifying the HTTP GET operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with fully documented parameters, the description is largely sufficient. Without an output schema, some return-format details are missing, but the tool's purpose and invocation requirements are clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description does not need to re-explain parameters. The description mentions the optional 'from' date, but the schema already documents this precisely with the yyyy-mm-dd pattern.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly identifies the resource scope: business + practitioner + appointment type, with 'single next bookable slot' distinguishing it from listing many slots. It effectively differentiates from sibling tools like cliniko_list_available_times.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by targeting the single next bookable slot, optionally from a date, which tells an agent when this tool is appropriate. It does not explicitly name alternatives or provide when-not-to-use guidance, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
