EU261 Flight Compensation
Server Details
EU261 flight delay compensation: check eligibility, compute EV, track fares. 6 tools, 35+ airports.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- MrSucik/eu261-mcp
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.2/5 across 6 of 6 tools scored.
Each tool has a distinct purpose: eligibility check, expected value computation, distance calculation, price history retrieval, airport listing, and price recording. No overlap or ambiguity.
Most tools follow verb_noun snake_case pattern (check_eligibility, compute_ev, list_airports, record_price, get_price_history). 'distance' is a minor outlier as a single noun, but its function is clear.
Six tools cover the core domain of EU261 flight compensation (eligibility, expected value, distance, airports, pricing) without excess. The scope is well-defined.
The set covers main compensation-related tasks: eligibility, expected value, distance bands, and airport info. Pricing tools are tangential but useful. Missing live claim submission, but that's beyond scope.
Available Tools
6 toolscheck_eligibilityBInspect
Check if a flight qualifies for EU261 delay compensation and compute the € amount
| Name | Required | Description | Default |
|---|---|---|---|
| origin | Yes | Origin airport IATA code (e.g. VIE) | |
| destination | Yes | Destination airport IATA code (e.g. JFK) | |
| carrier_country | No | Carrier's home country code (e.g. AT for Austrian) | |
| arrival_delay_minutes | Yes | Arrival delay in minutes (0 = on time) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states the tool checks and computes, but omits traits like being read-only, authentication needs, rate limits, or what happens for non-eligible flights.
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?
One sentence, 12 words, entirely to the point with no unnecessary content. Highly concise and front-loaded with the core action.
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?
While the tool is simple, the description lacks any mention of output structure, edge cases, or return format. With no output schema, more detail would help complete the picture. Still, the core functionality is covered.
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 baseline is 3. The description does not add additional meaning beyond the schema's param definitions; it only mentions the broader context of EU261 compensation.
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 clearly states the tool checks EU261 delay compensation eligibility and computes the € amount. It uses a specific verb and resource, and is distinct from sibling tools like compute_ev or distance.
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?
No guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description implies the use case but does not provide explicit when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compute_evBInspect
Compute EU261 expected value for a trip: net cost after compensation probability
| Name | Required | Description | Default |
|---|---|---|---|
| origin | Yes | Origin IATA code | |
| fare_eur | Yes | Round-trip fare in EUR | |
| destination | Yes | Destination IATA code | |
| routing_type | Yes | Routing type — determines payable-delay probability |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose behavioral traits like read/write nature, side effects, or required permissions. Lacks transparency for a computation tool.
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?
Single short sentence, front-loaded with action. However, it may be too terse, missing necessary detail for agent understanding.
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 and complex operation (expected value under EU261). Description is minimal, lacking output format, computational assumptions, or edge cases.
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 baseline is 3. Description adds no extra meaning beyond schema; 'net cost after compensation probability' is vague and does not clarify parameters.
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?
Description clearly states it computes EU261 expected value, a specific verb-resource combination. It is distinct from sibling tools like check_eligibility or distance.
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?
No explicit guidance on when to use or alternatives. The purpose implies use for financial evaluation, but no exclusions or comparison to siblings are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
distanceBInspect
Calculate great-circle distance between two airports and the EU261 compensation band
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Destination IATA | |
| from | Yes | Origin IATA |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose behavioral traits (e.g., read-only nature, side effects, error conditions). Only states the calculation action.
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?
Single sentence, front-loaded with key action, no redundant words. It efficiently communicates the tool's core function.
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?
Lacks details about output format (distance unit, compensation band mapping) and relationship to sibling tools (e.g., check_eligibility). No output schema further reduces completeness.
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% with descriptions for both parameters ('Origin IATA' and 'Destination IATA'). Description adds no extra meaning beyond the schema, so baseline 3 is appropriate.
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?
Description clearly states it calculates great-circle distance and EU261 compensation band. Verb 'calculate' and specific resources (distance, compensation band) make purpose distinct from siblings like list_airports or check_eligibility.
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?
No explicit guidance on when to use this tool vs alternatives. Implied usage for distance/compensation but no exclusions or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_price_historyBInspect
Retrieve stored price history for a route
| Name | Required | Description | Default |
|---|---|---|---|
| route | Yes | Route, e.g. VIE-JFK |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral traits, but it only states a read operation. It omits important details such as whether authentication is required, if results are paginated, or what the time range of history 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?
The description is a single, concise sentence. It is front-loaded with the key purpose, though it could be slightly more detailed without becoming verbose.
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?
Given there is no output schema, the description should provide more context about what 'price history' entails (e.g., format, time range). The current description is too vague to fully inform an agent about the tool's output.
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?
The schema covers the single parameter 'route' with an example. The description adds no additional meaning beyond the schema, resulting in a baseline score of 3.
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 clearly states the action ('Retrieve'), the resource ('stored price history'), and the context ('for a route'). It effectively distinguishes from sibling tools like 'record_price' (which writes) and 'check_eligibility' (which checks a different property).
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?
No guidance is provided on when to use this tool versus alternatives. For example, it does not mention that this retrieves historical data while 'record_price' is for storing new data, leaving the agent to infer usage from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_airportsAInspect
List all known airports with EU status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states the purpose but does not disclose any behavioral traits such as pagination, rate limits, or side effects.
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?
The description is a single, complete sentence with no wasted words.
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 simple list tool with no parameters or output schema, the description adequately conveys the tool's function. It could mention the output format but is generally complete.
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?
There are 0 parameters and schema coverage is 100%. Following the baseline rule for 0 parameters, a score of 4 is appropriate.
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 clearly states the action (list), the resource (airports), and a specific qualifier (with EU status). It distinguishes this tool from sibling tools like check_eligibility and distance.
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?
No guidance is provided on when to use this tool versus others. There is no mention of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
record_priceCInspect
Store a fare observation for trend tracking (builds price history in DO state)
| Name | Required | Description | Default |
|---|---|---|---|
| route | Yes | Route, e.g. VIE-JFK | |
| source | No | e.g. 'Google Flights' | |
| carrier | Yes | ||
| routing | Yes | e.g. 'nonstop' or '1-stop via FRA' | |
| fare_eur | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. It only says 'store' and 'builds price history' without mentioning idempotency, update vs insert behavior, return values, or side effects. This is insufficient for a write operation.
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?
Single sentence conveying core purpose without waste. However, it is so short that it may be under-specified; conciseness is valued but not at the cost of completeness.
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 tool with 5 parameters, no output schema, and no annotations, the description is incomplete. It lacks behavioral details (e.g., duplicate handling, response format) and fails to provide enough context for correct use.
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?
Description adds no information about parameters beyond the input schema. Two parameters (carrier, fare_eur) lack schema descriptions and are not clarified in the tool description. Schema coverage is 60%, and the description does not compensate for the missing param details.
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?
Description clearly states the action (Store) and resource (fare observation), and explains the purpose (trend tracking, builds price history). It implies a write operation distinct from siblings like get_price_history, but does not explicitly differentiate.
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?
No guidance on when to use this tool versus alternatives. No when-not or prerequisites mentioned. For a write tool alongside a read sibling (get_price_history), explicit usage context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!