Skip to main content
Glama

Find bookings by guest name, email, or booking code

bookings.list
Read-onlyIdempotent

Find bookings by guest name, email, or booking code. Combine text, date, and status filters, or omit them to list all bookings. Supply both start and end when filtering dates. The range includes bookings departing on start or arriving on end. Returns up to 100 bookings per page. Set page to the returned page.next to continue. A next value of 0 marks the last page.

Input Schema

NameRequiredDescriptionDefault
endNoEnd hotel date in YYYY-MM-DD format, on or after start, including arrivals on this date. Required with start.
pageNoPage number, starting at 1. Omit for the first page. Use the returned page.next number to continue.
queryNoPartial guest name, email, or booking code. Code spaces and separators are ignored. Omit to list all matches.
startNoStart hotel date in YYYY-MM-DD format, including departures on this date. Required with end.
statusesNoBooking statuses to include. Omit or use [] for all statuses.
stayStatusesNoRoom stay statuses to include. Dates and status must match the same room. Use booked for rooms awaiting check-in, staying for occupied rooms, or completed for checked-out rooms.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / result / properties / items / items / properties / products
      Added value: +{
      +  "description": "Active extras and fees. Prices and totals use the booking currency.",
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "bookingUnitId": {
      +        "type": "string"
      +      },
      +      "mode": {
      +        "enum": [
      +          "once",
      +          "per_night",
      +          "per_person",
      +          "per_person_per_night"
      +        ],
      +        "type": "string"
      +      },
      +      "name": {
      +        "type": "string"
      +      },
      +      "price": {
      +        "type": "string"
      +      },
      +      "quantity": {
      +        "type": "number"
      +      },
      +      "total": {
      +        "type": "string"
      +      },
      +      "type": {
      +        "enum": [
      +          "product",
      +          "fee"
      +        ],
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "name",
      +      "type",
      +      "mode",
      +      "price",
      +      "quantity",
      +      "total"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
  2. Changed3 schema fields changed
    • addedInput schema / properties / stayStatuses
      Added value: +{
      +  "default": [],
      +  "description": "Room stay statuses to include. Dates and status must match the same room. Use booked for rooms awaiting check-in, staying for occupied rooms, or completed for checked-out rooms.",
      +  "items": {
      +    "enum": [
      +      "booked",
      +      "staying",
      +      "completed"
      +    ],
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedOutput schema / properties / result / properties / items / items / properties / units / items / properties / stayStatus
      Added value: +{
      +  "enum": [
      +    "booked",
      +    "staying",
      +    "completed"
      +  ],
      +  "type": "string"
      +}
    • changedOutput schema / properties / result / properties / items / items / properties / units / items / required
      Previous value: -[
      -  "unitId",
      -  "checkinAt",
      -  "checkoutAt",
      -  "guests"
      -]New value: +[
      +  "unitId",
      +  "stayStatus",
      +  "checkinAt",
      +  "checkoutAt",
      +  "guests"
      +]
  3. Changed5 schema fields changed
    • addedInput schema / examples
      Added value: +[
      +  {
      +    "end": "2026-11-07",
      +    "query": "Jordan",
      +    "start": "2026-11-01",
      +    "statuses": [
      +      "booked"
      +    ]
      +  }
      +]
    • changedInput schema / properties / end / description
      Previous value: -"Optional range end in YYYY-MM-DD format. Supply start too."New value: +"End hotel date in YYYY-MM-DD format, on or after start, including arrivals on this date. Required with start."
    • changedInput schema / properties / page / description
      Previous value: -"Page number to fetch."New value: +"Page number, starting at 1. Omit for the first page. Use the returned page.next number to continue."
    • changedInput schema / properties / start / description
      Previous value: -"Optional range start in YYYY-MM-DD format. Supply end too."New value: +"Start hotel date in YYYY-MM-DD format, including departures on this date. Required with end."
    • changedInput schema / properties / statuses / description
      Previous value: -"Optional booking statuses."New value: +"Booking statuses to include. Omit or use [] for all statuses."
  4. Changed4 schema fields changed
    • changedInput schema / properties / end / description
      Previous value: -"Range end in YYYY-MM-DD format."New value: +"Optional range end in YYYY-MM-DD format. Supply start too."
    • addedInput schema / properties / query
      Added value: +{
      +  "default": "",
      +  "description": "Partial guest name, email, or booking code. Code spaces and separators are ignored. Omit to list all matches.",
      +  "maxLength": 200,
      +  "type": "string"
      +}
    • changedInput schema / properties / start / description
      Previous value: -"Range start in YYYY-MM-DD format."New value: +"Optional range start in YYYY-MM-DD format. Supply end too."
    • removedInput schema / required
      Removed value: -[
      -  "start",
      -  "end"
      -]
  5. Changed2 schema fields changed
    • addedOutput schema / properties / result / properties / items / items / properties / units / items / properties / cancellationPolicy
      Added value: +{
      +  "additionalProperties": false,
      +  "properties": {
      +    "enabled": {
      +      "type": "boolean"
      +    },
      +    "noshow": {
      +      "additionalProperties": false,
      +      "properties": {
      +        "type": {
      +          "type": "string"
      +        },
      +        "value": {
      +          "type": "number"
      +        }
      +      },
      +      "required": [
      +        "type"
      +      ],
      +      "type": "object"
      +    },
      +    "presetId": {
      +      "type": "string"
      +    },
      +    "tiers": {
      +      "items": {
      +        "additionalProperties": false,
      +        "properties": {
      +          "minDays": {
      +            "type": "number"
      +          },
      +          "penalty": {
      +            "additionalProperties": false,
      +            "properties": {
      +              "type": {
      +                "type": "string"
      +              },
      +              "value": {
      +                "type": "number"
      +              }
      +            },
      +            "required": [
      +              "type"
      +            ],
      +            "type": "object"
      +          }
      +        },
      +        "required": [
      +          "minDays",
      +          "penalty"
      +        ],
      +        "type": "object"
      +      },
      +      "type": "array"
      +    }
      +  },
      +  "required": [
      +    "enabled",
      +    "tiers",
      +    "noshow"
      +  ],
      +  "type": "object"
      +}
    • addedOutput schema / properties / result / properties / items / items / properties / units / items / properties / id
      Added value: +{
      +  "type": "string"
      +}
  6. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive behavior, so the bar is lower. The description still adds real value with the pagination contract (100 per page, set page to page.next, next=0 means last page) and the requirement that start and end be supplied together — behavior an agent could not infer from annotations alone.

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?

Four short sentences, front-loaded with purpose then filters then pagination; every sentence carries actionable information with no repetition of the schema or title.

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?

For a read-only search tool with an output schema and full schema descriptions, the description covers what remains: filter combination, date-pair requirement, and how to page through results. Nothing needed to invoke it correctly is missing.

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 a 3 is the baseline, but the description adds cross-parameter semantics beyond the schema: start and end must be supplied as a pair, and the range is inclusive at both edges (departures on start, arrivals on end). That is genuine added meaning, though per-parameter format details remain in the schema.

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 ('Find') and resource ('bookings') plus the searchable identifiers (guest name, email, booking code), which clearly separates it from the sibling bookings.get lookup-by-id.

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?

'Combine text, date, and status filters, or omit them to list all bookings' gives clear context for both filtered and unfiltered use. However, it never names an alternative (e.g. bookings.get or guests.bookings) or states when not to use this tool, so it stops short of a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources