Skip to main content
Glama
h-kazuki-pixel

booking-gap MCP Server

List individual dead gaps

booking_gap_list_dead
Read-onlyIdempotent

List the structurally unsellable gaps in a booking calendar, longest first, showing date, time window, and resource to inspect underlying bookings.

Instructions

List the individual gaps that are structurally unsellable, longest first, so the underlying bookings can be inspected.

Use this after booking_gap_analyze when the aggregate number needs to be traced back to concrete dates and resources.

Args: same as booking_gap_analyze, plus

  • limit (number, default 30, max 500): how many gaps to list

  • resourceFilter (string, optional): only list gaps for this resource

  • outputJson (boolean, default false): return machine-readable JSON instead of a table

Returns a table of date, weekday, time window, length and resource.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoHow many gaps to list.
bookingsNoBookings as structured objects. Provide either this or bookingsCsv.
currencyNoCurrency symbol prefix, e.g. "¥".
periodEndNoLast date to analyse (YYYY-MM-DD). Defaults to the latest booking.
resourcesNoResources to include even when they have no bookings in the period.
hourlyRateNoOptional hourly price, used to express dead time as an amount. No default.
outputJsonNoReturn JSON (gaps plus summary) instead of a formatted table.
bookingsCsvNoBookings as pasted CSV or TSV with a header row. Column names are matched in English and Japanese (start/end/resource/date/status, 開始時刻/終了時刻/部屋/日付/ステータス). A separate date column plus HH:mm times is supported.
periodStartNoFirst date to analyse (YYYY-MM-DD). Defaults to the earliest booking.
openingHoursYesOpening hours. Use "default" for the usual day and override individual weekdays as needed, e.g. {"default": [["09:00","22:00"]], "sun": [["10:00","18:00"]]}. Use "24:00" to close at midnight.
resourceFilterNoOnly list gaps for this resource.
timezoneOffsetNoVenue timezone offset, used only for inputs that carry an explicit offset or "Z".+09:00
turnoverMinutesNoCleaning or changeover time required between two bookings.
minBookingMinutesNoShortest booking a customer is allowed to make.
slotGranularityMinutesNoAllowed booking start interval, measured from midnight (30 means :00 and :30).
Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint, so the description only needs to add non-safety behavior. It adds sorting ('longest first'), output shape ('table of date, weekday, time window, length and resource'), and the machine-readable JSON option, going beyond the structured fields.

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 sentences plus a short bullet-style list, with the core action in the first sentence. Every sentence adds purpose, usage timing, or output details; no filler.

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

Completeness4/5

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

Given no output schema, the description adequately specifies the return table columns and default/option behavior. It also references booking_gap_analyze for inherited args, but lightly—an agent unfamiliar with that sibling might need more parameter context, though the schema fills the gap.

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%, so all 15 parameters already have descriptions. The description contributes the higher-level relationship 'same as booking_gap_analyze' and highlights the three tool-specific parameters, but adds little semantics beyond what the schema provides.

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 description opens with a specific verb+object ('List the individual gaps that are structurally unsellable') and immediately states ordering ('longest first'). It distinguishes itself from sibling tools by noting it traces aggregate numbers back to concrete dates/resources, complementing booking_gap_analyze.

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 explicit usage context: 'Use this after booking_gap_analyze when the aggregate number needs to be traced back...' This clearly positions when to choose this tool over the analysis sibling and implies it is not for first-pass analysis.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/h-kazuki-pixel/booking-gap-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server