aCheck whether a delayed, cancelled or overbooked flight is owed compensation under EU261, UK261, Israel's Aviation Services Law or Canada's APPR. Looks up the flight by number and date, estimates the amount per passenger, and returns a pre-filled claim link. No sign-in needed.
Scored across 3 tools
Each tool has a recognisably different role: data lookup (look_up_flight), eligibility verdict (check_flight_compensation) and claim routing (get_claim_link). The only overlap is that check_flight_compensation also performs a flight lookup when route or delay is missing, which could make an agent unsure whether to call look_up_flight first; the descriptions mostly resolve this but not explicitly.
All three names are snake_case verb_noun phrases with concrete objects (check_flight_compensation, get_claim_link, look_up_flight). The verbs differ (check/get/look_up) but each matches the action, so the pattern is predictable and readable.
Three tools is on the thin side but matches a narrow, well-defined purpose: look up a flight, assess compensation, and route to a claim. Each tool earns its place with no filler; a fourth tool is not obviously needed.
The surface covers the full read-only lifecycle from flight data to eligibility across four jurisdictions to claim submission options. Gaps are minor and by design: nothing handles post-submission claim status, rejection/appeal guidance, or batch assessment for multiple passengers beyond a per-passenger estimate.
Preliminary check of whether a delayed, cancelled or overbooked flight (or a missed connection) is likely to be owed fixed compensation under EU261, UK261, Israel's Aviation Services Law or Canada's APPR, and the estimated amount per passenger, from the route distance, the delay at the final destination, the notice given, the operating airline and the time limit. Given a flight number and date, it looks the flight up when the route or the delay is missing. Returns a verdict, an estimate and a short explanation. Read-only: files nothing and stores nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| toCode | Yes | Final destination airport, 3-letter IATA code. | |
| fromCode | Yes | Departure airport, 3-letter IATA code (the first airport of the booking). | |
| delayBand | No | For DELAYED or MISSED_CONNECTION: arrival at the final destination was under 3 hours late (lt3), 3–4 hours (3to4) or over 4 hours (gt4). | |
| deniedType | No | For DENIED_BOARDING: refused boarding against their will (involuntary) or gave up the seat for a deal (voluntary). | |
| disruption | Yes | What happened. | |
| flightDate | No | Flight date, YYYY-MM-DD. Lets the check refuse a claim that is too old. | |
| airlineIata | No | Operating airline, 2-character IATA code (e.g. LH, BA, LY). Decides coverage of flights INTO Europe, the UK, Israel or Canada. | |
| airlineIsEU | No | Only if the airline code is unknown: is the operating airline licensed in the EU/EEA or the UK? | |
| cancelNotice | No | For CANCELLED: how far ahead the airline told them — under 7 days, 7 to 13 days, or 14 days or more. | |
| flightNumber | No | Flight number, e.g. LH400. Optional; with flightDate, the flight is looked up when the route or delay is missing. | |
| passengerCount | No | How many passengers on the booking were affected. Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description reinforces this with concrete consequence language ('files nothing and stores nothing'), which is more actionable than the hint alone. It also discloses a non-obvious behavioral trait — that providing flightNumber plus flightDate triggers an internal flight lookup when route or delay is missing — and states what the return contains. It doesn't cover failure modes or how confident or approximate the estimate is.
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?
Three sentences, front-loaded with the core purpose and ending with the return shape and safety profile. Dense but not padded; the jurisdiction list is long yet each item carries information. A slightly tighter phrasing of the closing sentence would earn a 5.
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 11-parameter tool with no output schema, the description still explains what comes back (verdict, estimate, explanation), what inputs drive it, the fallback lookup path, and the read-only guarantee. An agent can call this correctly without opening anything else.
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%, so the baseline would be 3, but the description adds domain meaning by naming the actual decision inputs — route distance, delay at the final destination, notice given, operating airline and the time limit — which tells the agent why delayBand, cancelNotice, airlineIata and flightDate matter. That is real value beyond the field-level descriptions.
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 ('preliminary check of whether ... is likely to be owed fixed compensation'), names the four jurisdictions covered, and enumerates the disruption types handled. It is clearly distinguishable from the siblings look_up_flight and get_claim_link because it produces a verdict and estimate rather than a lookup or a filing link.
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 word 'preliminary' plus 'Read-only: files nothing and stores nothing' makes the intended position in the workflow clear: assess eligibility before doing anything else. It stops short of naming get_claim_link as the follow-on tool or stating explicit exclusions, so it is clear context rather than a full when/when-not/alternatives statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two ways to claim: directly from the airline, free; or through FlightCompensations.com, with a link to its claim form pre-filled with the known flight details. With FlightCompensations.com the passenger keeps 100% of the compensation; a flat success fee per passenger is invoiced separately, only once the claim is won. Nothing is filed.
| Name | Required | Description | Default |
|---|---|---|---|
| toCode | No | Final destination airport, 3-letter IATA code. | |
| fromCode | No | Departure airport, 3-letter IATA code. | |
| disruption | No | ||
| flightDate | No | YYYY-MM-DD | |
| flightNumber | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive and closed-world, so the safety bar is low. The description still adds genuinely non-obvious behavior: no claim is filed ('Nothing is filed') and the fee is a flat per-passenger success fee invoiced only after a win. It stops short of saying what the caller receives (a URL? a message?).
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?
Three compact sentences with the practical distinction (free vs. service) front-loaded and the fee caveat placed clearly. Slight marketing tone in the fee paragraph, but nothing extraneous enough to trim.
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?
No output schema exists, but the key consumer-facing facts — that a pre-filled link is produced, that nothing is submitted, and that the fee only applies on success — are all disclosed. An agent can relay this to a passenger without misrepresenting consequences.
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 60%, with flightNumber and the disruption enum undocumented in-schema, and zero parameters are required — a notable quirk. The description only gestures at 'known flight details' being pre-filled and clarifies nothing about which identifiers are needed to build the link or what happens if they are omitted.
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 explains the two claim routes and that a pre-filled link exists, but it never states plainly that the tool returns/builds that link. It reads as informational copy about claiming rather than a specific verb+resource, and it does not distinguish itself from check_flight_compensation or look_up_flight.
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?
Presenting the 'two ways to claim' implicitly frames when to use this tool, but there is no explicit guidance on when to call it versus the siblings (e.g. only after check_flight_compensation confirms eligibility). No exclusion conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Looks up a flight's record by flight number and scheduled departure date: route, operating airline, scheduled and actual departure and arrival times (local), arrival delay in minutes and status (on time, delayed, cancelled, diverted). When the record shows the flight on time or under three hours late, it also checks the same flight number on the previous day (an overnight delay) and returns the questions that decide whether compensation may still be owed. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Scheduled departure date, YYYY-MM-DD. | |
| flightNumber | Yes | Flight number as on the ticket, e.g. LH400, BA2490, LY315. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive and open-world, but the description adds genuinely non-obvious behavior: a secondary lookup of the same flight number on the previous day triggered only under a delay threshold, and that the response includes questions bearing on compensation eligibility. It does not mention auth needs, rate limits, or what happens when no record is found, keeping it short of a 5.
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?
A single dense but front-loaded sentence leading with verb, resource and keys, then the conditional behavior, closed by a one-word 'Read-only.' qualifier. No filler and every clause conveys distinct 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?
With no output schema and only two parameters, the description compensates well by enumerating the returned fields and the conditional previous-day check. It leaves open the boundary case of what is returned for delays of three hours or more, and what an empty result looks like.
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 both parameters are already documented with format examples in the schema. The description only restates them ('by flight number and scheduled departure date') without adding constraints such as whether dates must be in the past or timezone handling for the date. Baseline 3 applies when the schema does the heavy lifting.
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 ('Looks up a flight's record') plus the two lookup keys and enumerates the returned fields (route, airline, times, delay, status). It never names the sibling tool check_flight_compensation, so an agent can't tell from this description alone which of the two to call first for a compensation question.
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?
Usage context is implied rather than stated: the read-only record lookup is described, and a conditional branch ('when the record shows the flight on time or under three hours late...') is disclosed. There is no explicit when-to-use, when-not-to-use, or pointer to check_flight_compensation / get_claim_link as alternatives.
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_compensationget_claim_linklook_up_flight
Add one secure layer between your agents and this server.