Free check: does an airline owe you cash for a delayed or cancelled flight in Canada?
Scored across 3 tools
The core verdict tool is clearly distinct from the two lookup helpers, and find_airline vs find_airport are separated by entity (carrier vs airport). Minor risk that an agent parsing a flight number might pick the wrong resolver, but the descriptions disambiguate well.
All three tools use a consistent snake_case verb_noun pattern (check_*, find_*, find_*). Names are predictable and readable.
Three tools is thin but each earns its place: one core decision engine and two small resolvers that feed it. It fits the narrow purpose of a single-question compensation checker.
Verdict, amount, per-passenger breakdown, and filing deadline are covered, but there is no way to verify a flight's actual delay/cancellation status, check appeal paths, or generate a claim — agents must supply all inputs from the user.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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? |
| Name | Required | Description |
|---|---|---|
| verdict | Yes | |
| moreInfo | Yes | |
| amountCadMax | Yes | |
| amountCadMin | Yes | |
| deadlineSoon | Yes | |
| whereToClaim | Yes | |
| lastDayToFile | Yes | |
| euOrUkRulesMayAlsoApply | Yes |
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.
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.
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.
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.
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.
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.
Find an airline’s 2-character code from a flight number (e.g. "AC 857") or a name (e.g. "WestJet"). An airline missing from the list can still be checked by its code.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | A flight number or an airline name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds that the underlying airline list may be incomplete, which is useful disclosure, but says nothing about ambiguous matches, no-match behavior, or whether one or many results come back.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with no waste; the core lookup purpose and input formats come first, with the edge-case note last.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup with no output schema, the description correctly states the return value and the accepted inputs. It could go further on match ambiguity or failure behavior, but nothing essential for invoking the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter is already documented as "a flight number or an airline name." The description adds concrete format examples ("AC 857", "WestJet"), which clarify the accepted shapes beyond the schema's prose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource plus the exact return value: an airline's 2-character code. The examples ("AC 857", "WestJet") and the resource (airline) make it unmistakable against siblings find_airport and check_flight_compensation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains the two accepted lookup modes (by flight number or by name) and adds a fallback hint that airlines not in the list can still be resolved by code. It doesn't name an alternative tool or state when not to use this one, but the context for calling it is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search airports by city, name or IATA code. Returns up to 8 matches with their IATA codes; Canadian airports are listed first.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | City, airport name or code, e.g. "toronto" or "YUL". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: a result cap of 8 matches, that IATA codes are returned, and that Canadian airports are prioritized in ordering — details an agent cannot get from annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste, and the search criteria are front-loaded before the return behavior. Every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with no output schema, the description covers purpose, lookup keys, result size, and result ordering. The only minor gap is not spelling out the no-match or ambiguous-match behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single 'query' parameter is fully documented with examples already. The description echoes the same three lookup dimensions (city, name, IATA code) without adding syntax, format, or length guidance, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Search airports') and narrows the searchable fields to city, name, or IATA code. Sibling tools like find_airline make the resource distinction implicit rather than stated, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when the tool applies by listing the accepted lookup keys, but it never mentions prerequisites, exclusions, or when to prefer find_airline or other siblings. Usage is inferable but not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_flight_compensation4 fields changedInput schema / properties / actualArrival / descriptionPrevious 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."Input schema / properties / arrivalDelayAdded 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"
+}Input schema / properties / scheduledArrival / descriptionPrevious 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."Input schema / requiredPrevious 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"
+]check_flight_compensationfind_airlinefind_airportEU261/UK261 flight compensation check, rights and claim letters. Free.
Find flight compensation, refunds and forgotten subscriptions you're owed; drafts claims for you.
Flight compensation claims info and submission via AI agents
EU261 flight delay compensation: check eligibility, compute EV, track fares. 6 tools, 35+ airports.
Add one secure layer between your agents and this server.
