Skip to main content
Glama

MAQAMI Travel

get_flights_bookings_bookingid_cancellations

Read-onlyIdempotent

Overview

Returns refund eligibility, estimated refund amounts, and penalty details for a booking without actually cancelling it. Use this before calling POST /flights/bookings/{bookingId}/cancellations to understand the financial impact of cancellation.

When to Use

  • Pre-cancellation review — Show the customer the potential maximum refund (not guaranteed) before they confirm cancellation

  • Refund estimation — Display potential maximum refund and penalty amounts in the booking management UI (refund is not granted until cancel completes)

  • Eligibility check — Determine whether the booking is within the void window (isVoidable) or eligible for a partial refund (isRefundable)

What You Get

  • confidence — How reliable the quote is (confirmed, estimated, heuristic, unknown)

  • isRefundable / isVoidable — Quick eligibility flags

  • refund / penalty — Aggregate amounts with margin applied. refund is the potential maximum the airline may refund — not a granted/guaranteed amount

  • penalties[] — Itemised penalty breakdown when available

  • tickets[] — Per-ticket detail when available

  • destination — Where refunded money goes (original_payment, agency_deposit, voucher, etc.)

  • vouchers[] — Airline travel vouchers / credit-shells when destination is voucher; omitted when absent. Distinct from LiteAPI discount voucherCode on prebook

Concurrent cancellation

If a cancellation was already submitted and is still awaiting provider confirmation, this endpoint returns HTTP 409 with code 49007 (CONCURRENT_OPERATION). A new quote is not available until that cancellation completes or fails.

Refund amount caveat

The refund amount on a cancellation quote is the potential maximum the airline may refund if cancellation proceeds under the quoted conditions. It is an estimate for decision-making only and is not granted — the final refund (if any) is determined when cancellation completes and may be lower or zero. The refund may arrive asynchronously once the airline determines the final amount.

Key Features

  • Non-destructive — Does not cancel the booking; safe to call before user confirmation

  • Margin-applied pricing — All amounts (including voucher pricing.display) reflect the same margin applied at booking time

Quick Start

Provide the bookingId from POST /flights/bookings in the URL path. Every call hits the upstream provider — do not place this on a hot polling loop.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bookingIdYesThe unique booking identifier

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses the HTTP 409 / code 49007 concurrent-operation behavior, that every call hits the upstream provider (no hot polling), that refunds are potential-maximum and not granted, margin-applied pricing, and that refunds may arrive asynchronously. Annotations only cover the safety profile, so this adds substantial new operational context.

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

Conciseness4/5

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

Front-loaded with Overview and sectioned headers, so it is easy to scan. However it is lengthy and repeats the 'potential maximum, not guaranteed' refund caveat across three separate sections, which is more redundancy than needed.

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, yet the description enumerates the return fields (confidence, isRefundable/isVoidable, refund/penalty, penalties[], tickets[], destination, vouchers[]) and explains the caveats around them. An agent has everything needed to call and interpret this tool correctly.

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?

Only one parameter with 100% schema coverage, so baseline is 3. The description adds value by specifying the origin of the value ('bookingId from POST /flights/bookings in the URL path'), which the schema's terse 'unique booking identifier' does not convey.

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 (returns refund eligibility, estimated refund amounts, and penalty details for a booking) and explicitly scopes it as read-only versus the sibling POST cancellations endpoint. An agent can distinguish this quote endpoint from `post_flights_bookings_bookingid_cancellations` immediately.

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 says to use this before calling `POST /flights/bookings/{bookingId}/cancellations`, and enumerates three concrete use cases (pre-cancellation review, refund estimation, eligibility check). Alternatives and the ordering condition are stated, not inferred.

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