Gaplessly Booking

Start an appointment booking

start_appointment_booking

Read-onlyIdempotent

Turn a time from find_appointment_times into a link the guest taps to finish booking. This does NOT book anything: it returns a short-lived URL on the venue's own booking page, already opened at that service, that staff member and that exact time, where the guest enters their own name, email and phone and confirms.

Give the guest the url and say plainly that the booking is not made until they open it. Never ask the guest for their contact details to pass here; this tool does not take them, and the page collects them directly. Nothing is reserved in the meantime, so a popular time can still go before they tap.

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": {
      "slotToken": "<slotToken>",
      "serviceId": "<serviceId>"
    },
    "name": "start_appointment_booking"
  }
}

Input Schema

Name	Required	Description
`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`.
`serviceId`	Yes	The same service id passed to find_appointment_times, from get_venue. The link opens on this service.
`slotToken`	Yes	A `slotToken` from find_appointment_times or find_table_times, copied exactly. It is signed and carries the venue and the time inside the signature, so it cannot be edited, built by hand, or used at a different venue. It expires about 30 minutes after the search.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 2, 2026

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",
-  "slotToken",
-  "serviceId"
-]New value: +[
+  "slotToken",
+  "serviceId"
+]

AddedOct 5, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnlyHint/idempotent/non-destructive) by explaining the actual mechanics: a short-lived URL on the venue's own page, nothing reserved in the meantime, and a slot can be lost before the guest taps. That 'no hold' caveat is the key behavior an agent would otherwise get wrong.

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

Conciseness5/5

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

Front-loads the core transformation, then the 'does not book' correction, then the guest-facing instructions. Every sentence carries distinct, non-repeated information despite the length.

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?

No output schema exists, so the description must explain the return value — it does, naming the `url` field and its short-lived, venue-hosted nature. Combined with the no-reservation caveat, an agent has everything needed to call it and relay the result correctly.

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

Parameters3/5

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

Schema coverage is 100% and the property descriptions already explain slug, serviceId and the signed/expiring slotToken in detail, so the schema does the heavy lifting. The description adds essentially no parameter-level detail beyond naming `url` as the output to hand over, which places it at the baseline.

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+resource: it turns a time slot from find_appointment_times into a booking URL. It immediately excludes the nearby interpretation ('This does NOT book anything'), which cleanly separates it from find_appointment_times and start_table_booking.

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?

Explicitly names the upstream source (a time from find_appointment_times) and the downstream action (give the guest the url and tell them the booking isn't made until they open it). It also states a negative rule — never ask the guest for contact details — which is exactly the guidance an agent needs to avoid misuse.

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?