Gaplessly Booking

Find table times

find_table_times

Read-onlyIdempotent

Free table times at one restaurant or venue for one party size, over up to two weeks. Use find_appointment_times for a salon or clinic instead.

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 the venue has nothing at that party size that day, which usually means closed or fully booked.

Each day lists at most 10 times unless maxPerDay says otherwise, spread across the day; omitted says how many more exist. To answer "around 7pm" or "lunch", send near, partOfDay, notBefore or notAfter. A party above the venue's online limit gets no times: the result carries groupEnquiry (a link and any contact details the venue published) to give the guest instead.

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": {
      "partySize": "<partySize>"
    },
    "name": "find_table_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).
`partySize`	Yes	How many people are coming, including the person booking.

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

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.7/5.0

Behavior5/5

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

Annotations already cover read-only/idempotent/non-destructive, and the description adds substantial context beyond them: the slotToken is signed, expires in ~30 minutes, must be passed back verbatim, and must not be reused across venues. It also discloses default result capping (10/day), the `omitted` counter, and the groupEnquiry fallback — none of which is derivable from annotations.

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?

Three tight paragraphs: what it does and its alternative, then the token contract (the highest-risk detail), then result shaping and the group-enquiry edge case. Front-loaded, no filler, and each paragraph maps to a distinct agent decision.

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?

With no output schema, the description carries the return-shape burden and does so: `at`, `slotToken`, `times`, `omitted`, `groupEnquiry`. Combined with the exhaustive param schema and safety annotations, an agent has everything needed to call it and interpret the result.

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 baseline is 3, but the description adds real usage meaning: it explains that near/partOfDay/notBefore/notAfter exist to answer queries like 'around 7pm' or 'lunch', and that maxPerDay spreads results and drives `omitted`. It does not add anything for partySize or slug 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?

Opens with a specific verb and resource plus scope: 'Free table times at one restaurant or venue for one party size, over up to two weeks.' It immediately names the sibling it is not (find_appointment_times for salons/clinics), so an agent can distinguish it without opening the schema.

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

Usage Guidelines4/5

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

Explicitly routes the salon/clinic case to find_appointment_times and explains the empty-array condition and the over-limit groupEnquiry path. It does not explicitly route the follow-up booking action to start_table_booking, leaving that to inference from the slotToken paragraph.

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?