FlightPayback

Check flight compensation

check_flight_compensation

Read-only

Check whether an airline owes cash compensation for a delayed or cancelled flight under Canada's Air Passenger Protection Regulations, and how much. Ask the passenger for every answer; don't guess. Returns the verdict, amount per passenger and the last day to file. General information, not legal advice.

Input Schema

Name	Required	Description
`notice`	Yes	When did the airline tell the passenger? "within_14_days" includes being told at the airport.
`reason`	Yes	The reason the airline gave, mapped to the closest value. Airline operations: crew_shortage (Crew or staff shortage), scheduled_maintenance (Scheduled maintenance), schedule_or_aircraft_change (Schedule change or aircraft swap), airline_it_problem (Airline's computer or IT problem). Safety: mechanical_issue (Mechanical or technical problem), safety_other (Another safety reason). Outside the airline: weather (Weather), air_traffic_control (Air traffic control), airport_operations (Airport problem (e.g. de-icing, runway, fuelling)), security_threat (Security threat), medical_emergency (Medical emergency), wildlife_strike (Bird or wildlife strike), labour_disruption (Strike or labour disruption), manufacturer_defect (Aircraft defect announced by the manufacturer or regulator), government_or_police_order (Order from government, police or airport security), war_or_unrest (War or political unrest), illegal_act (Sabotage or another illegal act). Not sure: no_reason_given (They didn't give a clear reason), not_remembered (I don't remember), other (Something else).
`charter`	Yes	Was it a charter or package-holiday flight? Use "unsure" if the passenger does not know.
`outcome`	Yes	"travelled" = reached the destination (original or new flight); "refunded" = took a refund instead; "other" = e.g. made their own way.
`disruption`	Yes	Was the flight delayed or cancelled?
`flightDate`	Yes	Original scheduled departure date, YYYY-MM-DD.
`originIata`	Yes	IATA code of the departure airport, e.g. YYZ. Use find_airport if unsure.
`arrivalDelay`	No	If the passenger doesn't know the exact times: how late they reached the final destination. When outcome is "travelled", give scheduledArrival + actualArrival, or this.
`actualArrival`	No	When the passenger actually arrived at the final destination (aircraft door opened), local time there: YYYY-MM-DDTHH:mm.
`connectionIatas`	No	IATA codes of connecting airports, in order. Empty for a direct flight.
`destinationIata`	Yes	IATA code of the FINAL destination on the original ticket (not a connection).
`scheduledArrival`	No	Scheduled arrival at the final destination, as on the original ticket, local time there: YYYY-MM-DDTHH:mm. With actualArrival; or use arrivalDelay instead.
`alreadyCompensated`	Yes	Has the passenger already been paid compensation for this disruption (by the airline or under another country's rules)?
`blamedEarlierFlight`	Yes	Did the airline say the problem was caused by an earlier flight?
`marketingCarrierIata`	Yes	2-character code of the airline on the ticket: the letters of the flight number, e.g. AC for AC 857.
`operatingCarrierIata`	No	Only if a different airline actually flew the plane ("operated by ..."): its 2-character code.
`delayAtRefundAtLeast3h`	No	Only for a delayed flight where the passenger took a refund: was it at least 3 hours late at that point?
`acceptedVoucherInWriting`	Yes	Did the passenger accept a voucher or credit instead of cash, in writing?

Output Schema

Name	Required	Description	Default
`verdict`	Yes
`moreInfo`	Yes
`amountCadMax`	Yes
`amountCadMin`	Yes
`deadlineSoon`	Yes
`whereToClaim`	Yes
`lastDayToFile`	Yes
`euOrUkRulesMayAlsoApply`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 26, 2026

changedInput schema / properties / actualArrival / description

Previous value: -"Required if outcome is \"travelled\": when the passenger actually arrived at the final destination (aircraft door opened), local time there: YYYY-MM-DDTHH:mm."New value: +"When the passenger actually arrived at the final destination (aircraft door opened), local time there: YYYY-MM-DDTHH:mm."

addedInput schema / properties / arrivalDelay

Added value: +{
+  "description": "If the passenger doesn't know the exact times: how late they reached the final destination. When outcome is \"travelled\", give scheduledArrival + actualArrival, or this.",
+  "enum": [
+    "under_3h",
+    "3_to_6h",
+    "6_to_9h",
+    "9h_plus"
+  ],
+  "type": "string"
+}

changedInput schema / properties / scheduledArrival / description

Previous value: -"Scheduled arrival at the final destination, as on the original ticket, local time there: YYYY-MM-DDTHH:mm."New value: +"Scheduled arrival at the final destination, as on the original ticket, local time there: YYYY-MM-DDTHH:mm. With actualArrival; or use arrivalDelay instead."

changedInput schema / required

Previous value: -[
-  "disruption",
-  "originIata",
-  "destinationIata",
-  "marketingCarrierIata",
-  "charter",
-  "flightDate",
-  "scheduledArrival",
-  "outcome",
-  "notice",
-  "reason",
-  "blamedEarlierFlight",
-  "acceptedVoucherInWriting",
-  "alreadyCompensated"
-]New value: +[
+  "disruption",
+  "originIata",
+  "destinationIata",
+  "marketingCarrierIata",
+  "charter",
+  "flightDate",
+  "outcome",
+  "notice",
+  "reason",
+  "blamedEarlierFlight",
+  "acceptedVoucherInWriting",
+  "alreadyCompensated"
+]

First observedOct 23, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered; the description adds genuinely new behavioral context — that answers must be elicited from the passenger rather than inferred, and that output is 'general information, not legal advice'. The named return components (verdict, amount per passenger, filing deadline) are somewhat redundant given the output schema exists.

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 the purpose, then the elicitation rule, then what comes back, then the disclaimer. Nothing repeats the schema or annotations and every sentence carries an actionable instruction.

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?

For an 18-parameter, 12-required rule engine, the description covers purpose, input sourcing discipline, output shape and legal disclaimer, and the output schema covers the return values. A minor gap is that it doesn't state applicability (e.g. flights to/from/within Canada), which determines whether calling it is even meaningful.

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 description coverage is 100%, so the enum mapping and format details are already fully documented; baseline would be 3. The description adds one rule the schema does not state — that each parameter must be sourced from the passenger rather than guessed — which affects how the agent fills all 18 fields.

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+legal regime: 'Check whether an airline owes cash compensation for a delayed or cancelled flight under Canada's Air Passenger Protection Regulations, and how much.' The scope (Canada, APPR, cash compensation, delay/cancellation) makes it unmistakable against the lookup siblings find_airline and find_airport.

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?

'Ask the passenger for every answer; don't guess' gives a clear operating context for when and how to call it (interview-driven, not speculative). It doesn't name exclusions or explicitly contrast with the sibling lookups, but with only two IATA-resolver siblings there is little ambiguity to resolve.

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

All FlightPayback 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?