Xona Dental Gateway

List a clinic's public booking slots

list_public_booking_slots

Read-onlyIdempotent

Read open times from a clinic's own online scheduler, by practice_slug, for one service_id between date_from and date_to (the clinic's dates, both included, at most 14 days). Each time carries starts_at, start_local (the time at the clinic), time_zone and booking_url, the page where the patient books that time (Xona's page on that service and day where Xona books the clinic's scheduler, else the clinic's own booking page); earliest is the first one; preferred_time puts the closest times first. An answer may be up to 5 minutes old: read_at says when the clinic's scheduler was read and age_seconds how long ago; fresh: true reads this clinic again (twice a minute per clinic; past that the answer says when it next can).

Input Schema

Name	Required	Description
`fresh`	No	Read this clinic's scheduler now rather than from a read up to 5 minutes old
`date_to`	Yes	Last day to read (inclusive), at most 13 days after date_from
`date_from`	Yes	First day to read, in the clinic's time zone; today or later
`service_id`	Yes	A service_id from list_public_booking_services, or from a soonest search row's services
`practice_slug`	Yes
`preferred_time`	No	The patient's preferred local start time, 24-hour HH:MM; the closest times come first

Output Schema

Name	Required	Description	Default
`slots`	Yes
`date_to`	No
`read_at`	No
`earliest`	No
`readable`	Yes
`use_tool`	No
`date_from`	No
`next_step`	Yes
`time_zone`	No
`fresh_note`	No
`service_id`	No
`age_seconds`	No
`booking_url`	No
`practice_slug`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 10, 2026

addedInput schema / properties / fresh

Added value: +{
+  "description": "Read this clinic's scheduler now rather than from a read up to 5 minutes old",
+  "type": "boolean"
+}

addedOutput schema / properties / age_seconds
```
Added value: +{
+  "type": "integer"
+}
```
addedOutput schema / properties / fresh_note
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / read_at

Added value: +{
+  "format": "date-time",
+  "type": "string"
+}

Changed3 schema fields changedOct 8, 2026
- addedOutput schema / properties / booking_url
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / earliest / properties / booking_url
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / slots / items / properties / booking_url
```
Added value: +{
+  "type": "string"
+}
```

Changed18 schema fields changedOct 8, 2026

removedInput schema / properties / action_id

Removed value: -{
-  "maxLength": 128,
-  "minLength": 16,
-  "type": "string"
-}

addedInput schema / properties / date_from

Added value: +{
+  "description": "First day to read, in the clinic's time zone; today or later",
+  "format": "date",
+  "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+  "type": "string"
+}

addedInput schema / properties / date_to

Added value: +{
+  "description": "Last day to read (inclusive), at most 13 days after date_from",
+  "format": "date",
+  "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+  "type": "string"
+}

removedInput schema / properties / end

Removed value: -{
-  "format": "date-time",
-  "maxLength": 64,
-  "type": "string"
-}

addedInput schema / properties / practice_slug

Added value: +{
+  "maxLength": 140,
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / preferred_time

Added value: +{
+  "description": "The patient's preferred local start time, 24-hour HH:MM; the closest times come first",
+  "pattern": "^([01][0-9]|2[0-3]):[0-5][0-9]$",
+  "type": "string"
+}

addedInput schema / properties / service_id / description

Added value: +"A service_id from list_public_booking_services, or from a soonest search row's services"

removedInput schema / properties / start

Removed value: -{
-  "format": "date-time",
-  "maxLength": 64,
-  "type": "string"
-}

changedInput schema / required

Previous value: -[
-  "action_id",
-  "service_id",
-  "start",
-  "end"
-]New value: +[
+  "practice_slug",
+  "service_id",
+  "date_from",
+  "date_to"
+]

removedOutput schema / properties / action_id
```
Removed value: -{
-  "type": "string"
-}
```
addedOutput schema / properties / date_from
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / date_to
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / earliest

Added value: +{
+  "properties": {
+    "ends_at": {
+      "format": "date-time",
+      "type": "string"
+    },
+    "id": {
+      "type": "string"
+    },
+    "provider_id": {
+      "type": "string"
+    },
+    "provider_name": {
+      "type": "string"
+    },
+    "service_id": {
+      "type": "string"
+    },
+    "start_local": {
+      "type": "string"
+    },
+    "starts_at": {
+      "format": "date-time",
+      "type": "string"
+    },
+    "time_zone": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "service_id",
+    "starts_at",
+    "ends_at"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / next_step
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / readable
```
Added value: +{
+  "type": "boolean"
+}
```
addedOutput schema / properties / service_id
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / time_zone
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / required

Previous value: -[
-  "slots"
-]New value: +[
+  "practice_slug",
+  "readable",
+  "slots",
+  "next_step"
+]

Changed3 schema fields changedOct 2, 2026
- addedOutput schema / properties / slots / items / properties / provider_id
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / slots / items / properties / start_local
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / slots / items / properties / time_zone
```
Added value: +{
+  "type": "string"
+}
```
First observedSep 18, 2026

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive, but the description adds substantial behavior the agent could not otherwise know: answers may be up to 5 minutes stale, read_at/age_seconds expose staleness, fresh forces a re-read, and there is a rate limit of twice a minute per clinic with a next-allowed hint. That is exactly the kind of operational context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the verb and the three key filters, then structured to explain returned fields and the freshness/rate-limit model. It is dense and semicolon-heavy, but each clause carries distinct information with little redundancy against the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, yet the description still maps the important ones (starts_at, start_local, time_zone, booking_url including which page is used, earliest). Combined with the staleness and rate-limit disclosure, an agent has everything needed to call it and interpret the result correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 83%, so baseline is 3, and the description genuinely adds meaning: preferred_time 'puts the closest times first', fresh re-reads rather than using a stale answer, and the date window bounds (both inclusive, at most 14 days) are restated with intent. It does not add syntax detail for practice_slug, which the schema also leaves undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — reading open times from a clinic's own online scheduler — and scopes it by practice_slug, service_id and date range. The phrase 'a clinic's own online scheduler' implicitly separates it from the sibling list_xona_booking_slots (Xona's scheduler) and from list_public_booking_services.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied: you need a service_id 'from list_public_booking_services, or from a soonest search row's services', which routes the agent to a predecessor tool. However, it never states when to prefer this over list_xona_booking_slots or when to follow up with choose_public_booking_time, so no explicit when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Xona Dental Gateway tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?