Skip to main content
Glama

FlightFix

by io.github.everyai-com
OverviewDiscussionsAdmin

Generate claim letter

generate_claim_letter
Read-onlyIdempotent

Draft a formal EU261/UK261 compensation claim letter (subject, legal basis, amount, 14-day payment request, escalation notice) for the passenger to send themselves, plus sending tips. Nothing is sent. Use after check_compensation and pass its amount. Do NOT use to check eligibility; use check_compensation.

Input Schema

NameRequiredDescriptionDefault
schemeNoLegal basis. Default: UK261 if departing the UK, else EU261 (without claimed_amount, worked out from the route; errors if neither applies).
arrivalYesArrival airport 3-letter IATA code, case-insensitive, e.g. JFK
currencyNoCurrency of the claim. Default GBP for UK261, EUR for EU261.
departureYesDeparture airport 3-letter IATA code, case-insensitive, e.g. LHR
flight_dateYesScheduled flight date, YYYY-MM-DD, e.g. 2026-09-01
airline_nameYesOperating airline, e.g. "British Airways"
flight_numberYesFlight number, e.g. BA117
claimed_amountNoAmount claimed, e.g. 600. If omitted, computed from the route like check_compensation (EUR 250/400/600 or GBP 220/350/520 by distance); required if an airport is unknown.
passenger_nameYesPassenger's full name as on the booking, e.g. "Jane Smith"
incident_summaryNoOne sentence on what happened, e.g. "the flight arrived 4 hours late due to a technical fault". Default generic wording.
booking_referenceNoBooking/PNR reference, e.g. ABC123. Optional.

Output Schema

NameRequiredDescriptionDefault
letterYesFull letter text, ready to copy and send.
schemeYesLegal basis used in the letter.
subjectYesSuggested email or letter subject line.
disclaimerYesNot-legal-advice disclaimer to show the user.
sending_tipsYesPractical tips for sending and follow-up.
claimed_amountYesAmount and currency claimed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / claimed_amount / description
      Previous value: -"Amount claimed, normally check_compensation's amount, e.g. 600. Default 250."New value: +"Amount claimed, e.g. 600. If omitted, computed from the route like check_compensation (EUR 250/400/600 or GBP 220/350/520 by distance); required if an airport is unknown."
    • changedInput schema / properties / scheme / description
      Previous value: -"Legal basis. Default UK261 if departing the UK, else EU261."New value: +"Legal basis. Default: UK261 if departing the UK, else EU261 (without claimed_amount, worked out from the route; errors if neither applies)."
  2. Changed17 schema fields changed
    • changedInput schema / properties / airline_name / description
      Previous value: -"Name of the airline"New value: +"Operating airline, e.g. \"British Airways\""
    • addedInput schema / properties / airline_name / minLength
      Added value: +1
    • changedInput schema / properties / arrival / description
      Previous value: -"IATA code"New value: +"Arrival airport 3-letter IATA code, case-insensitive, e.g. JFK"
    • changedInput schema / properties / booking_reference / description
      Previous value: -"Booking reference number"New value: +"Booking/PNR reference, e.g. ABC123. Optional."
    • changedInput schema / properties / claimed_amount / description
      Previous value: -"Amount of compensation claimed"New value: +"Amount claimed, normally check_compensation's amount, e.g. 600. Default 250."
    • addedInput schema / properties / claimed_amount / minimum
      Added value: +0
    • changedInput schema / properties / currency / description
      Previous value: -"Currency of the claimed amount, ISO code"New value: +"Currency of the claim. Default GBP for UK261, EUR for EU261."
    • changedInput schema / properties / departure / description
      Previous value: -"IATA code"New value: +"Departure airport 3-letter IATA code, case-insensitive, e.g. LHR"
    • changedInput schema / properties / flight_date / description
      Previous value: -"YYYY-MM-DD"New value: +"Scheduled flight date, YYYY-MM-DD, e.g. 2026-09-01"
    • addedInput schema / properties / flight_date / minLength
      Added value: +1
    • changedInput schema / properties / flight_number / description
      Previous value: -"e.g. BA117"New value: +"Flight number, e.g. BA117"
    • addedInput schema / properties / flight_number / minLength
      Added value: +1
    • changedInput schema / properties / incident_summary / description
      Previous value: -"Brief description of the delay/cancellation"New value: +"One sentence on what happened, e.g. \"the flight arrived 4 hours late due to a technical fault\". Default generic wording."
    • changedInput schema / properties / passenger_name / description
      Previous value: -"Full name of the passenger"New value: +"Passenger's full name as on the booking, e.g. \"Jane Smith\""
    • addedInput schema / properties / passenger_name / minLength
      Added value: +1
    • changedInput schema / properties / scheme / description
      Previous value: -"Compensation scheme, EU261 or UK261"New value: +"Legal basis. Default UK261 if departing the UK, else EU261."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "claimed_amount": {
+      "description": "Amount and currency claimed.",
+      "properties": {
+        "currency": {
+          "description": "EUR or GBP.",
+          "type": "string"
+        },
+        "value": {
+          "description": "Amount claimed.",
+          "type": "number"
+        }
+      },
+      "required": [
+        "value",
+        "currency"
+      ],
+      "type": "object"
+    },
+    "disclaimer": {
+      "description": "Not-legal-advice disclaimer to show the user.",
+      "type": "string"
+    },
+    "letter": {
+      "description": "Full letter text, ready to copy and send.",
+      "type": "string"
+    },
+    "scheme": {
+      "description": "Legal basis used in the letter.",
+      "enum": [
+        "EU261",
+        "UK261"
+      ],
+      "type": "string"
+    },
+    "sending_tips": {
+      "description": "Practical tips for sending and follow-up.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "subject": {
+      "description": "Suggested email or letter subject line.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "subject",
+    "scheme",
+    "claimed_amount",
+    "letter",
+    "sending_tips",
+    "disclaimer"
+  ],
+  "type": "object"
+}
  3. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "letter": {
-      "description": "The generated claim letter as a plain text string.",
-      "type": "string"
-    },
-    "letter_html": {
-      "description": "The generated claim letter as an HTML string.",
-      "type": "string"
-    },
-    "letter_pdf": {
-      "description": "The generated claim letter as a PDF file in base64 encoding.",
-      "format": "byte",
-      "type": "string"
-    }
-  },
-  "required": [
-    "letter"
-  ],
-  "type": "object"
-}New value: +null
  4. Changed7 schema fields changed
    • addedInput schema / properties / airline_name / description
      Added value: +"Name of the airline"
    • addedInput schema / properties / booking_reference / description
      Added value: +"Booking reference number"
    • addedInput schema / properties / claimed_amount / description
      Added value: +"Amount of compensation claimed"
    • addedInput schema / properties / currency / description
      Added value: +"Currency of the claimed amount, ISO code"
    • addedInput schema / properties / incident_summary / description
      Added value: +"Brief description of the delay/cancellation"
    • addedInput schema / properties / passenger_name / description
      Added value: +"Full name of the passenger"
    • addedInput schema / properties / scheme / description
      Added value: +"Compensation scheme, EU261 or UK261"
  5. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "letter": {
+      "description": "The generated claim letter as a plain text string.",
+      "type": "string"
+    },
+    "letter_html": {
+      "description": "The generated claim letter as an HTML string.",
+      "type": "string"
+    },
+    "letter_pdf": {
+      "description": "The generated claim letter as a PDF file in base64 encoding.",
+      "format": "byte",
+      "type": "string"
+    }
+  },
+  "required": [
+    "letter"
+  ],
+  "type": "object"
+}
  6. First observed

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description still adds value beyond them by clarifying 'Nothing is sent' — the letter is drafted for the passenger to send — plus that sending tips are included, which annotations cannot express.

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?

Three tight sentences, front-loaded with what is produced, followed by the sequencing rule and the exclusion. No filler and nothing redundant with the schema.

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 an 11-parameter tool whose schema covers every parameter and which has an output schema, the description supplies the missing operational context: workflow ordering, the no-send behavior, and the sibling it must not replace. Nothing needed to invoke it correctly is absent.

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?

With schema coverage at 100%, baseline is 3, but the description adds cross-tool semantics: it tells the agent to pass check_compensation's amount into this call, linking the required claimed_amount to a prior step. That is genuinely new information not present 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 (draft) and resource (EU261/UK261 compensation claim letter) and enumerates the letter's contents (subject, legal basis, amount, 14-day payment request, escalation notice). It explicitly contrasts itself with the sibling check_compensation, so an agent can distinguish it without opening either schema.

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?

Gives ordered usage ('Use after check_compensation and pass its amount'), an explicit negative case ('Do NOT use to check eligibility'), and names the correct alternative ('use check_compensation'). This is the full when/when-not/alternative pattern.

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

All FlightFix toolsInspect
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