Gaplessly Booking

Find appointment times

find_appointment_times

Read-onlyIdempotent

Free appointment times at one venue for one service, over up to two weeks. For salons, clinics, studios and anywhere a guest books a named service with a provider. Use find_table_times for a restaurant instead.

Needs a service id from get_venue. Each returned time has an at label to show the guest and a slotToken. The token is the booking handle: it is signed, it expires in about 30 minutes, and it is the only way a time can be booked later. Pass it back exactly as given, never edited, and never reuse one from a different venue. An empty times array for a day means that day is genuinely unavailable, not that something failed.

Each day lists at most 10 times unless maxPerDay says otherwise, spread across the day; omitted says how many more exist. To answer "around 6pm" or "afternoons", send near, partOfDay, notBefore or notAfter instead of asking for everything.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "serviceId": "<serviceId>"
    },
    "name": "find_appointment_times"
  }
}

Input Schema

Name	Required	Description
`days`	No	How many consecutive days to search from that day, 1 to 14. Defaults to 3.
`from`	No	Which day to start from: the word "today", the word "tomorrow", or an exact calendar date as YYYY-MM-DD. Resolved against the venue's own current date, which is often not yours. Do not send a phrase like "next Tuesday" or a time of day; both are rejected.
`near`	No	A 24 hour time as HH:MM, for example 19:00 for 7pm. When a day has more times than maxPerDay, keep the ones closest to this.
`slug`	No	The venue's booking slug, exactly as find_venues or get_venue returned it or as it appears in the venue's own booking link: the last path segment of gaplessly.com/book/<slug>, or the first label of <slug>.gaplessly.com. Not the business name; use find_venues to turn a name into a slug.
`venue`	No	Alias of `slug`, kept for existing clients. Send `slug`.
`notAfter`	No	Drop times later than this 24 hour HH:MM.
`maxPerDay`	No	Most times to return per day, 1 to 40. Defaults to 10. Past it, the times are spread across the day (or nearest `near`) and `omitted` says how many were left out.
`notBefore`	No	Drop times earlier than this 24 hour HH:MM.
`partOfDay`	No	Only times in this part of the day: morning (before 12:00), afternoon (12:00 to 16:59), evening (17:00 on).
`serviceId`	Yes	One service id from this venue's get_venue result. Not a service name.

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedNov 2, 2026

addedInput schema / properties / maxPerDay

Added value: +{
+  "description": "Most times to return per day, 1 to 40. Defaults to 10. Past it, the times are spread across the day (or nearest `near`) and `omitted` says how many were left out.",
+  "maximum": 40,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / near

Added value: +{
+  "description": "A 24 hour time as HH:MM, for example 19:00 for 7pm. When a day has more times than maxPerDay, keep the ones closest to this.",
+  "type": "string"
+}

addedInput schema / properties / notAfter

Added value: +{
+  "description": "Drop times later than this 24 hour HH:MM.",
+  "type": "string"
+}

addedInput schema / properties / notBefore

Added value: +{
+  "description": "Drop times earlier than this 24 hour HH:MM.",
+  "type": "string"
+}

addedInput schema / properties / partOfDay

Added value: +{
+  "description": "Only times in this part of the day: morning (before 12:00), afternoon (12:00 to 16:59), evening (17:00 on).",
+  "enum": [
+    "morning",
+    "afternoon",
+    "evening"
+  ],
+  "type": "string"
+}

addedInput schema / properties / slug

Added value: +{
+  "description": "The venue's booking slug, exactly as find_venues or get_venue returned it or as it appears in the venue's own booking link: the last path segment of gaplessly.com/book/<slug>, or the first label of <slug>.gaplessly.com. Not the business name; use find_venues to turn a name into a slug.",
+  "type": "string"
+}

changedInput schema / properties / venue / description

Previous value: -"The venue's booking slug, exactly as get_venue returned it or as it appears in the venue's own booking link: the last path segment of gaplessly.com/book/<slug>, or the first label of <slug>.gaplessly.com. Not the business name."New value: +"Alias of `slug`, kept for existing clients. Send `slug`."

changedInput schema / required

Previous value: -[
-  "venue",
-  "serviceId"
-]New value: +[
+  "serviceId"
+]

Changed2 schema fields changedOct 5, 2026

changedInput schema / properties / days / description

Previous value: -"How many consecutive days to search from that day, 1 to 14. Defaults to 7."New value: +"How many consecutive days to search from that day, 1 to 14. Defaults to 3."

changedInput schema / properties / venue / description

Previous value: -"The venue's booking slug, exactly as get_venue returned it or as it appears in the venue's own booking link (the last path segment of gaplessly.com/book/<slug>). Not the business name."New value: +"The venue's booking slug, exactly as get_venue returned it or as it appears in the venue's own booking link: the last path segment of gaplessly.com/book/<slug>, or the first label of <slug>.gaplessly.com. Not the business name."

First observedSep 30, 2026

TDQS

A4.6/5.0

Behavior4/5

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

With readOnly/idempotent annotations already covering safety, the description adds the real behavioral contract: the `slotToken` is signed, expires in ~30 minutes, must be returned verbatim, and cannot be reused across venues. It also preempts a false-failure reading of an empty `times` array and explains the `omitted` truncation signal. Minor gap: it never says what happens when the token has expired at booking time (error shape), which would help an agent recover.

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 purpose, then prerequisites, then the token contract, then paging behavior — a sensible ordering with little waste. It is on the long side for a 10-parameter tool, but nearly every sentence carries unique information; only the salon/clinic/studio enumeration is arguably padding.

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?

There is no output schema, so the description carries the return contract and does it: `at` label, `slotToken` as the sole booking handle, the `times` array, and `omitted` for truncation. Combined with full schema coverage, an agent has everything needed to call this correctly and hand results to `start_appointment_booking`.

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 100%, so the baseline is 3, but the description adds intent-level meaning the schema doesn't: it frames `near`/`partOfDay`/`notBefore`/`notAfter` as the answer to vague time-of-day requests and explains the interaction between `maxPerDay`, spreading, and `omitted`. It does not add much for `slug`/`venue` or `days` beyond what the schema already says.

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?

The opening sentence gives a specific verb, resource, unit (one venue, one service) and horizon (up to two weeks). It then names the sibling it is not — 'Use find_table_times for a restaurant instead' — so an agent can route without opening a schema.

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

Usage Guidelines5/5

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

It states the prerequisite (a serviceId from get_venue) and the alternative tool for restaurants. It also gives concrete routing guidance for fuzzy user requests: send `near`, `partOfDay`, `notBefore` or `notAfter` for 'around 6pm' rather than paging everything.

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

All Gaplessly Booking 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?