Skip to main content
Glama
h-kazuki-pixel

booking-gap MCP Server

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
booking_gap_analyzeA

Measure the shape of idle time in a time-based booking calendar, not just the utilization rate.

Two venues can both sit at 33% utilization while one has its idle time in long sellable blocks and the other has it scattered into slivers that can never be sold. This tool separates the two.

It classifies every gap between bookings as either:

  • sellable: long enough to book after turnover time and start-grid alignment are subtracted

  • structural dead time: too short to ever be sold under the current settings

Args:

  • bookings or bookingsCsv (required, exactly one)

  • openingHours (required)

  • minBookingMinutes, slotGranularityMinutes, turnoverMinutes: the settings that decide sellability

  • periodStart / periodEnd: analysis window (defaults to the span of the data)

  • resources: include resources that had no bookings

  • hourlyRate / currency: optional, expresses dead time as an amount

Returns a text report with utilization, sellable vs dead breakdown, fragmentation rate, a gap-length histogram, and a per-resource table.

Scope: exclusive resources only (rooms, studios, meeting rooms, treatment beds). Pooled shared seating, where any free seat can absorb a booking, uses a different model and is not supported.

Use when: "why is my utilization stuck", "how much of my empty time is actually sellable", "is my calendar fragmented". Don't use when: you want a recommended configuration — use booking_gap_simulate to compare options and decide yourself.

booking_gap_profileA

Show when structural dead time occurs, broken down by weekday and by hour of day.

The total dead-time figure from booking_gap_analyze says how much is lost. This says where to look. Dead time concentrated in one weekday or one part of the day usually points at a specific booking pattern rather than a general problem.

Gaps are distributed proportionally across the hours they span, so a 40-minute gap running 13:50-14:30 is attributed to both hours.

Args: same as booking_gap_analyze, plus

  • topCells (number, default 8): how many worst weekday x hour cells to list

Returns a text report with a weekday table, an hour-of-day bar chart, and the worst weekday x hour cells.

Use when: "which days are worst", "when does the fragmentation happen".

booking_gap_simulateA

Re-run the gap analysis under several booking configurations and compare how much structural dead time each one produces.

The first scenario is the baseline; every other scenario reports its delta against it. This answers questions like "if I allowed 30-minute bookings instead of 60, how many hours would stop being structurally unsellable".

Args:

  • the same booking data and openingHours as booking_gap_analyze

  • scenarios (required): array of { label, minBookingMinutes?, slotGranularityMinutes?, turnoverMinutes? }. Any omitted field falls back to the top-level setting, so scenarios can vary one dimension at a time.

Returns a comparison table of dead time, delta versus baseline, and fragmentation rate, optionally valued at hourlyRate.

Important: recovered minutes are an upper bound. They show what becomes sellable, not what will sell. This tool deliberately does not pick a winner — shorter slots also change price positioning and cleaning load, and those trade-offs belong to the operator.

booking_gap_list_deadA

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.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

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